Synchronisation problems

[vflam]

Environment

---

• Operating System: Linux
• Node Version: v16.18.0
• Nuxt Version: 3.5.3
• Nitro Version: 2.4.1
• Package Manager: npm@8.19.2
• Builder: vite
• User Config: ssr, telemetry, sourcemap, serverHandlers, vue, routeRules, vite, css, dir, plugins, modules, imports, electron, nitro, hooks, runtimeConfig, session
• Runtime Modules: @pinia-plugin-persistedstate/nuxt@1.1.1, @pinia/nuxt@0.4.11, @sidebase/nuxt-session@0.2.7

• Build Modules: -

Reproduction

I use mongodb driver for storageOptions but I think this would probably happen with any asyn storage. The problem I describe here does not happen when using memory storage.

I have 2 requests to my api, called in a sequence. First request modifies the session, second request reads it.

await fetch("endoint1"); // session modified
await fetch("endpoint2") // session read

When session value is read in endpoint2, the changes made in endpoint1 are absent.

I can mitigate that as a workaround doing something like:

await fetch("endpoint1"); 
await new Promise((resolve) => setTimeout(resolve, 2000));
await fetch("endpoint2");

I ended up using an other workaround, that is overwrite the session in the database myself instead of waiting for the plugin to do it, it solves my problem but may create other issues.

event.res.on('finish', async () => {
    // Session id may not exist if session was deleted
    const session = await getSession(event)
    if (!session) {
      return
    }

    await setStorageSession(session.id, event.context.session)
  })

It looks like h3 sends the response before the callbacks on the finished events are done so I'm not sure what to do about that.

Describe the bug

Using an async storage (in my case mongodb), when calling 2 requests in a sequence, first request modifies the session, the second reads it, data is not updated in the session in request 2.

Additional context

No response

Logs

No response

[Puneetk1103]

I am also facing the same issue in my project, the session data is getting overwritten by the new data in concurrent request

[agracia-foticos]

Same issue!