State leaking between concurrent sessions when useStore comes after an await on SSR

[iPrytz]

We have encountered this a few times, and I think really it's important to know about because it's hard to test and and an easy mistake to make. It can easily leak user data if not handled correctly.

Solution is to allways pass the pinia instance. How can we solve passing the pinia instance all the way to the API-functions in the example ?

Reproduction link

https://github.com/iPrytz/vue3-pinia-ssr-example

Steps to reproduce

1. Create a SSR Vue application
2. Create two stores, exampe userStore and myDataStore

• initialize userStore with some user data from session, example a sessionId
• in myDataStore get (and log) session data from userStore useUserStore().sessionId
• then do a fetch with await
• then get (and log) data from userStore useUserStore().sessionId again

3. When tested (for example with autocannon) with multiple different sessions fetching the SSR app at the same time, data will leak between the sessions. SessionId will be different the second time from useStore.
4. It is solved if const store = useUserStore() and store.sessionId is used both before and after await, but in more complex cases it can still be a missmatch.
   For example, in our store, we fetch specific user data connected to the sessionId, but before we do that we need to fetch and await the users profile settings, then we can fetch the specific user data. From our store we call the API and in the API-handler we then add the sessionId/token from userStore, and now we have a missmatch because we do useUserStore() after the await user profile while we have multipe requests comming in to our node server. So the sessionId/token added to the request is now from another user and we get mixed up data.

I added a repo to reproduce the problem, instructions how to test this is found in the README

Would also love to get some explanation on what is actually hapening here that is causing this behavior.

Thank you to everyone working on this project, you're awesome!! 💯 🙌

[posva]

You should indeed call useStore before the await or pass the pinia instance to avoid sharing the state across request. This is already documented. Improvements to docs are welcome though 🙌

[iPrytz]

I don't agree, at least the documentation is not clear enough in the examples.
I can definetly try to add some more examples to the domentation, but do you have time to have a look at the repo and give some feedback on how to best solve it in this scenario when a store is using another store after an await? How do i pass the pinia instance all the way to the api in the best way? Thank you for you time!

[posva]

I don’t have the availability right now but hopefully other people will be able to help you! I moved it to a discussion

[erikmode]

It would be nice if there at least where something that can warn us rookie developers from making this mistake. Would it for example be possible to create an eslint rule or something?

[niksy]

You should indeed call useStore before the await or pass the pinia instance to avoid sharing the state across request. This is already documented. Improvements to docs are welcome though 🙌

@posva if one wants (or somehow needs, e.g. stores are lazy loaded) to call useStore after awaited Promise, can this be achieved with following implementation (following example from Shared Actions section):

import { defineStore, getActivePinia } from 'pinia'
import { useUserStore } from './user'

export const useCartStore = defineStore('cart', {
  actions: {
    async orderCart() {
      // get currently active Pinia instance
      const pinia = getActivePinia();

      try {
        await apiOrderCart(user.token, this.items)
        // explictly pass Pinia instance to useStore
        const otherStore = useOtherStore(pinia)
        // another action
        this.emptyCart()
      } catch (err) {
        displayError(err)
      }
    },
  },
})

[posva]

Yes

[niksy]

It would be nice if there at least where something that can warn us rookie developers from making this mistake. Would it for example be possible to create an eslint rule or something?

@erikmode Very crude check can be made with ESLint AST selectors and no-restricted-syntax rule: https://astexplorer.net/#/gist/9662e2811caf3fdc80b021cf659798bf/f7d8e78a770d74bd1269783a1989dd37f9ef9987

This only works if you call your stores use{something}Store and async/await, thenables are not covered.