A complete solution for open data platforms, enterprise data catalogs, data lakes and data management. Open source, mature, fully-featured and production ready.

DataHub

Hi folks,
I re-deploy Datahub with helm chart. I set `replicaCount` to 2 for frontend. I'm using google OIDC for authen. I tried clear cookie on browser but I still got the under error. Any suggestion for me in this case.
```p.api.mvc.DefaultJWTCookieDataCodec - The JWT signature in the cookie does not match the locally computed signature with the server. This usually indicates the browser has a leftover cookie from another Play application, so clearing cookies may resolve this error message.```

I have two frontend pod. So, I guess the issue here that is the different of key on two pods (it's used to generate session - Play framework).
I can see on frontend codebase. We have two config and it's very confusing for me. What is the different of two variable in the configration?
```<https://github.com/datahub-project/datahub/blob/master/datahub-frontend/conf/application.conf#L286C1-L286C19>

<https://github.com/datahub-project/datahub/blob/master/datahub-frontend/conf/application.conf#L11>```

The first one is the one used to generate personal access tokens, the second is the one that Play-Pac4j uses to sign JWT tokens.

Are you using our helm charts to deploy? If so the keys should be controlled by the deployment and not at the pod level so they shouldn't be different

Thank <@UV5UEC3LN>,
From my point of view, the name of variable is confusing to understand. :smiley: . I found the solution for my problem. I'm using helm chart to deploy Datahub when I scale the Frontend service (helm upgrade) from 1 to 2 pod, the kubernetes will keep old pod and create a new pod.
Because I'm using default secret of chart, so the secret will be generated again. That mean, the old pod still have old `DATAHUB_SECRET` . The new pod still have new `DATAHUB_SECRET` . That is the problem here.