-
-
Notifications
You must be signed in to change notification settings - Fork 635
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
fix(vanilla): deal with promise resolving race condition #2199
fix(vanilla): deal with promise resolving race condition #2199
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 10ea181:
|
37037fb
to
2af5f05
Compare
Thanks. It would be really nice to have store api tests. Also, could you avoid |
09dee94
to
8ac41b8
Compare
8ac41b8
to
6e3c5b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for minor requests. I will do the rest afterwards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much for your help. This must be a huge bug fix.
Thanks for your help. Merge is blocked for me, kindly merge at the next opportunity. |
Related Issues or Discussions
#2192
Related Issue
#2191
Summary
Adds tests for the issue linked above.
Description of Issue
A primitive atom (
atomP
) exists and has a value (valueP
)An async atom (
atomA
) gets the value (valueAP
) from atomP and then has a delay (delayA
) before returning the value from atomP.A derived async atom (
atomB
) gets the value (valueBP
) from atomP and after a microtask or greater delay (delayB
) it gets the value (valueBA
) from atomA.The bug requires delayB < delayA.
So,
After all atoms mount,
atomP is changed twice with a delay (
delayC
) less than delayA.This first multi-change proceeds nominally. ✅
atomP is then changed twice again with a delay (
delayD
) less than delayA.This second multi-change does NOT proceed nominally.
The first value of this multi-change is used for ALL subsequent values of this multi-change.
Therefore, subsequent values use a stale value. ❌
Timing
See below for this timing in depth:
Theory
Likely, as a performance optimization there is logic in store.ts to reuse the existing value. The bug is probably due to caching the incorrect value.
The microsecond delay (delayB) in atomB is significant for some reason. Not sure why yet.
The
store.sub
is also significant for some reason.Unit Test
I'm having trouble getting a unit test to work with just the store. Subsequent fires of
setCount(increment)
do not cause asyncAtom.read to refire unless I use a React hook. Not sure why.It would be preferable to write a unit test and not depend on the React library for testing core Jotai functionality.
Check List
yarn run prettier
for formatting code and docshttps://codesandbox.io/s/jovial-kepler-d9v27h
Screen.Recording.2023-10-17.at.7.46.48.PM.mov