Redirection after updating User entity doesn't pick up last updates
I'm following the example in https://wasp.sh/docs/auth/social-auth/overview#example-allowing-user-to-set-their-username to complete the sign up by asking users to provide additional information in a SignupCompletionPage. Once I call the operation to update the User entity and I use
navigate('/home') to redirect back to the home page, the HomePage receives an old version of user which causes a redirect back to the SignupCompletionPage again. It looks like the me user doesn't get invalidated/updated on time, causing a stale consumption. I've noticed that if I call useAuth() before calling navigate('/home') this fixes the issue, but it seems to be a workaround more than a clean solution.Overview | Wasp
Social login options (e.g., Log in with Google) are a great (maybe even the best) solution for handling user accounts.
10 Replies
Hi @giallo. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
You're correct in observing that after updating the User entity (e.g., setting isSignupComplete), the HomePage may receive a stale version of the user object, causing an immediate redirect back to the SignupCompletionPage. This happens because the cache for the user (fetched via useAuth) is not always invalidated or refetched immediately after the update, leading to the consumption of outdated data.
Wasp relies on automatic entity-based query cache invalidation: when an Action that uses the same Entity as a Query is executed, Wasp will invalidate the relevant Query's cache, causing it to refetch data from the server. However, this mechanism depends on the Action being correctly associated with the User entity. If the Action updating the user does not declare it affects the User entity, Wasp will not know to invalidate the cache, and the stale user object will persist until the next refetch or reload. This is a known pitfall, as described in the Wasp documentation and issues:
Wasper has to remember to declare that the action is affecting certain entity although it doesn’t use it directly – this is extra mental work for Wasper and could result in errors.signUp action from TODO example injects User although it doesn't use it directly To ensure cache invalidation works as expected, make sure your Action that updates the User entity includes entities: [User] in its declaration. This will trigger Wasp to invalidate the user query and refetch the latest data. If you are already doing this and still experiencing the issue, it may be due to the timing of the cache invalidation and the navigation. Navigating away immediately after the update may not give the cache enough time to refetch the updated user. The workaround you found—calling useAuth() before navigating—forces a refetch, but as you noted, it's not ideal. Currently, Wasp does not provide a built-in, fine-grained way to await the cache update before navigation. For more advanced control, you may need to use mechanisms provided by react-query directly, as suggested in the docs:
We should think what is the solution we want to achieve here. Maybe supporting composability of the actions would be a solution... then we can know that signUp action also changes user, although it is not explicitly declared.
If that's an issue, you can use the mechanisms provided by react-query for now, and expect more direct support in Wasp for handling those use cases in a nice, elegant way.Actions > Cache Invalidation In summary: - Ensure your Action declares it affects the User entity. - If the problem persists, it's due to the timing of cache invalidation and navigation. - The workaround you found is valid, but not ideal. - For now, you may need to use react-query's manual cache invalidation or refetching for more precise control, until Wasp provides a more integrated solution. Let me know if you need an example of how to declare the Action or manually trigger a refetch! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @giallo, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
@kapa.ai I confirm the operation to update properties on the User entity explicitly declares the entity in
entities:
Let me check the knowledge base for you again. One moment! :books:
----------------------
Thank you for confirming that your action explicitly declares the User entity in entities. According to Wasp's documentation, this should trigger automatic cache invalidation for any queries that also use the User entity. In theory, after your updateUserRole action runs, the cache for queries like me (which fetches the current user) should be invalidated and refetched, ensuring the UI receives the latest user data when you navigate to /home Cache Invalidation.
However, your experience suggests that the invalidation and refetch may not complete before the navigation occurs, resulting in the HomePage consuming stale user data. This timing issue is not directly addressed in the official documentation, but it is a known limitation: Wasp's automatic invalidation is entity-based and may not always synchronize perfectly with immediate UI transitions. The documentation also notes that for more advanced or precise control, you may need to use react-query's lower-level APIs Advanced usage.
In summary:
- Declaring entities: [User] in your action is correct and should trigger invalidation.
- There may be a race condition between cache invalidation/refetch and navigation, which is not fully handled by Wasp's current automatic system.
- The workaround you found (triggering useAuth before navigation) is not officially documented but aligns with the need to ensure fresh data.
- For now, Wasp does not provide a built-in way to guarantee the cache is updated before navigation, and the knowledge sources do not mention a more robust solution.
If you need more precise control, you may consider using react-query's manual cache invalidation or refetching as a temporary solution until Wasp offers more advanced cache management features.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @giallo, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
Hey @giallo, this sounds interesting, something that we'll definitely want to handle. Do you mind sharing your code?
Sure thing! Let me setup a repro on a GitHub repo and I'll post it here soon!
@Filip I've pushed the repro here: https://github.com/gcacace/wasp-redirect-issue-repro
Upon signup, after email is confirmed you're redirected to the
/, then to /complete-signup as the username is null, then the expectation is to be back to /, but instead it's redirected back to /complete-signup, only after the 2nd time you fill the form it will successfully stay on /.GitHub
GitHub - gcacace/wasp-redirect-issue-repro
Contribute to gcacace/wasp-redirect-issue-repro development by creating an account on GitHub.
Should I open an issue on GitHub?
GitHub
Stale User entity after update and redirect · Issue #3009 · wasp-...
Describe the bug After completing post-signup user profile configuration by updating the User entity (specifically setting the username), the cached user data in user is not immediately invalidated...
Wohooo @giallo, you just became a Waspeteer level 2!
Thanks a lot @giallo, I'll check it out today or tomorrow and get back to you