Skip to content

fix: never use global context on the server side #2983

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: v3
Choose a base branch
from

Conversation

ivansky
Copy link

@ivansky ivansky commented May 27, 2025

when store is accessed and injection context is not found it falls back to global active pinia object,

although it is safe for client, on the server side there are could be many requests with their own context,

falling back to global state leads to race conditions and undefined behaviour,

this should be fixed once and for all!

it is probably a breaking change but a good one, I haven't tested this locally, I appreciate any help to improve this PR in order to make it good looking

Copy link

netlify bot commented May 27, 2025

Deploy Preview for pinia-official canceled.

Name Link
🔨 Latest commit 56d62d0
🔍 Latest deploy log https://app.netlify.com/projects/pinia-official/deploys/6835fe114850650008318757

@@ -43,7 +43,7 @@ interface _SetActivePinia {
* Get the currently active pinia if there is any.
*/
export const getActivePinia = () =>
(hasInjectionContext() && inject(piniaSymbol)) || activePinia
(hasInjectionContext() && inject(piniaSymbol)) || (import.meta.server ? throw new Error("Cannot get active pinia as it does not find context") : activePinia)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. This could be changed into a non breaking change by just showing an error and still returning the active pinia. The error should be in development only (like other warnings) and should not rely on import as it might not work in all scenarios

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think failing fast is the better approach when the global activePinia is accessed on the server, because:

  1. failing immediately makes the problem obvious rather than silently continuing with potentially incorrect behavior.
  2. allowing it to continue by returning activePinia could lead to dangerous state sharing between requests, which is particularly problematic in server environments.

maybe making the message is more clear would help huge

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be a breaking change. Also, I do prefer the error message because it feels less frustrating to users

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will leave the decision to you,

However, please keep in mind that the developers tend to ignore error messages, so they will make the same mistakes again and again, I would prefer it to fail that will indicate the mistake much faster.

@ivansky
Copy link
Author

ivansky commented May 27, 2025

@posva I removed throwing error, added console.error and fallback to createPinia() instead, please check.

@github-project-automation github-project-automation bot moved this to 🆕 Triaging in Pinia Roadmap Jun 3, 2025
@posva posva moved this from 🆕 Triaging to 💬 In discussion in Pinia Roadmap Jun 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 💬 In discussion
Development

Successfully merging this pull request may close these issues.

2 participants