Using CredentialsProvider, refreshed tokens not stored for next calls

[gcottenc]

Environment

System:
OS: Linux 5.4 Ubuntu 20.04.3 LTS (Focal Fossa)
CPU: (8) x64 Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
Memory: 2.67 GB / 31.31 GB
Container: Yes
Shell: 5.0.17 - /bin/bash
Binaries:
Node: 14.15.3 - /usr/local/bin/node
Yarn: 1.22.17 - /usr/local/bin/yarn
npm: 8.3.0 - /usr/local/bin/npm
Browsers:
Chrome: 96.0.4664.93
Firefox: 97.0.2

Reproduction URL

https://github.com/gcottenc/next-auth-example

Describe the issue

Using getSession from SSR (to implement authorized API calls for our needs) - as in https://next-auth.js.org/tutorials/securing-pages-and-api-routes -, once the access and refresh tokens are updated - as in https://next-auth.js.org/tutorials/refresh-token-rotation -, the next SSR with getSession will still see the old access and refresh tokens.
FWIW I tried to investigate nextauth source, and saw that the Set-Cookie from next/utils.js updating the session cookie storing the new token is performed as it should, but does not seem to reach the browser (when I look that up in web developer tools / network).
The above URL contains a simple minimal commit from next-auth-example that demonstrates the problem and a README file indicating precisely the steps to perform to try it.
Thanks for any help! I spent a lot of time on it and lost at what to do next to fix the problem :(

How to reproduce

(these instructions also in README of the above reproduction URL project)

Install:

a) npm install
b) create a .env.local with:
NEXTAUTH_URL=http://localhost:3001
NEXTAUTH_SECRET=3ec635dd8c7bce6790eeabe8d348abee5e9f82cc6650711eacc2cbd4935cfbee
c) npm run dev -- -p 3001
d) open http://localhost:3001 in your browser and check you see a home screen with a top-right signin button

Reproduce the problem:

1. sign in (filling username/password fields unnecessary)

2. click on the SSR link after 10 seconds from login (so that access
   token expired), logs show:

current access token expired on 1646822124490, pretend successful API refresh using refresh token dummy_refresh_token
new access token expiration 1646822185388
awaited getSession, access token is now: refreshed_access_token

3. click back and click on the SSR link again (no waiting necessary), logs show:

current access token expired on 1646822124490, pretend successful API refresh using refresh token dummy_refresh_token
new access token expiration 1646822197936
awaited getSession, access token is now: refreshed_access_token

=> demonstrating the fact the old access and refresh tokens are used, not the refreshed ones on step 2

Expected behavior

the new access and refresh token (returned by the jwt callback) should be used in subsequent calls to getSession (and next jwt callback)

[sich-mnc]

I am also working on this issue, with gcottenc.
It seems that the solution was in #4075
Specifically in the answer #4075 (comment) by ThangHuuVu

[balazsorban44]

#4075 (comment) is the correct/preferred solution here. For context, the getSession method does not update the cookie inside getServerSideProps as it doesn't care about the ctx.res object.

getServerSession will.