async atom resolves with stale value

[mindplay-dk]

just trying out Jotai and ran into this issue.

it appears the first resolution of a promise is able to override the resolution of a later promise:

as you can see, during the second run, the result we end up with is displaying the wrong content for id 9005 - it's actually the content from the post with id 9001, the one that displays initially.

here's the sandbox:

https://codesandbox.io/p/sandbox/cool-shape-4j92jf?file=%2FApp.tsx&utm_medium=sandpack

it's based on your example here:

https://tutorial.jotai.org/examples/hackerNews

the only difference is I introduced a delay to see how reliable it was:

function delay() {
  return new Promise(resolve => {
    setTimeout(resolve, Math.random()*2000 + 500);
  });
}

const postId = atom(9001)
const postData = atom(async (get) => {
  const id = get(postId)
  const response = await fetch(
    `https://hacker-news.firebaseio.com/v0/item/${id}.json`
  )
  await delay(); // 👈
  const data: PostData = await response.json()
  return data
})

this essentially just simulates a delay, which could happen on a slow network.

interestingly, if I add e.g. console.log("resolving", id) just before return data, I can see in the console that it is actually ignoring some of the delayed updates - so I think the intention was this sort of thing should work in general?

the issue is only triggered if you reload the page and then quickly hit the arrow button a few times.

so it would appear only the first promise can end up beating later promises in a race - after the first promise resolves, once the promise stream is going, so to speak, there is no problem.

am I explaining this well? 😅

[dai-shi]

the first resolution of a promise is able to override the resolution of a later promise

Yeah, it's one of the hardest challenges to implement Jotai.

so it would appear only the first promise can end up beating later promises in a race

No, I'm not sure if I understand your problem.

Oh, 9005 after the reload. Interesting. Why can it be not 9001 after the reload???

[dai-shi]

Hmm, it's not a race condition, but probably a behavior with promise cancellation with Suspense-compatible capability. If that's the case, it behaves like a bug, but working as intended, so it's a limitation for now. I would like to fix it somehow. No idea yet. Will put more effort later.

However, I'm still not sure why it behaves weirdly with "reload". Cache should be gone? I'm not sure if I fully understand the situation.

What you can help me with is writing a failing test. Would you be interested in tackling such a challenge?

[mindplay-dk]

actually I already attempted to reduce this to a minimal repro for a test, but I couldn't recreate the issue in a more minimal setting.

I don't know Jotai very well, I was just trying it out.

However, I'm still not sure why it behaves weirdly with "reload". Cache should be gone? I'm not sure if I fully understand the situation.

it's nothing specifically to do with reloading - certainly nothing to do with caching, I don't think.

here's a smaller repro making it easier for you to see the problem:

import { Suspense } from 'react'
import { Provider, atom, useAtom, useSetAtom } from 'jotai'

const fauxData = {
  9001: "ITEM 9001",
  9002: "ITEM 9002"
}

function pause(time) {
  return new Promise(resolve => {
    setTimeout(resolve, time);
  })
}

const postId = atom(9001)

const postData = atom(async (get) => {
  const id = get(postId)
  const data = Promise.resolve(fauxData[id]);
  await pause(3000);
  return data
})

function Id() {
  const [id] = useAtom(postId)
  return <h1>{id}</h1>;
}

function Next() {
  const setPostId = useSetAtom(postId)
  return (
    <button id="next" onClick={() => setPostId((id) => id + 1)}>
      <div>→</div>
    </button>
  )
}

function PostTitle() {
  const [data] = useAtom(postData)
  return (
    <>
      <pre>{JSON.stringify(data)}</pre>
    </>
  )
}

export default function App() {
  return (
    <Provider>
      <Id />
      <div>
        <Suspense fallback={<h2>Loading...</h2>}>
          <PostTitle />
        </Suspense>
      </div>
      <Next />
    </Provider>
  )
}

try this in the playground - when you see the arrow, click it within the first 3 seconds, you will see the problem.

what's even stranger though, is I tried to make it automatically click the button after 1.5 seconds, to illustrate the problem - paste this:

setTimeout(() => {
  console.log("clicking next");
  document.querySelector("#next").click();
}, 1500);

as you will see, the situation is reversed. (???)

that is, if you manually click the next-button, you end up with 9001 in the title, and 9002 in the content.

but if you add this code to click the next-button, you end up with 9002 in the title, and 9001 in the content - the reverse.

it's perplexing. why would clicking via code produce a different result from actually clicking the next-button on the screen???

very strange. 🤔

[dai-shi]

Thanks. I will try to reproduce it in a test setup later, but not very soon. Meanwhile, if anyone is interested, feel free to try it.

why would clicking via code produce a different result from actually clicking the next-button on the screen???

maybe because they have different priority. actual clicking has high priority, and setTimeout has low priority.

[mindplay-dk]

I also noticed, in some cases, the app doesn't seem to render at all until the first promise resolves? (is it suspended until it resolves?)

which I could sort of understand, given that the atom has no value at all, before the async operation completes.

but it made me think, maybe things would be simpler if async atoms could be given a default, initial value? like, for example, if you're expecting a Something[] then just initialize your async atom with an [] empty array - so that the app can render in an empty state.

might complicate typing a bit in some cases, but might be simpler?

[iwoplaza]

but it made me think, maybe things would be simpler if async atoms could be given a default, initial value? like, for example, if you're expecting a Something[] then just initialize your async atom with an [] empty array - so that the app can render in an empty state.

We can use the unwrap(anAsyncAtom) helper for that. While the atom is loading, the default value is undefined, but we can control that with the second parameter, unwrap(anAsyncAtom, (prev) => LoadingValue), so in your case, unwrap(anAsyncAtom, (prev) => prev ?? []). In the case of a custom pending value, make sure to either memoize the call to unwrap, or memoize the function that computes the pending value.

[dai-shi]

@mindplay-dk Hi, I just realized that it's probably because the older version of Jotai.
Can you try with the latest version please?

https://stackblitz.com/edit/vitejs-vite-56vtp9?file=src%2FApp.tsx&terminal=dev

[mindplay-dk]

yep, looks like it's resolved! was I not using the latest version at the time? or did you release a newer version since?

[dai-shi]

The example in the tutorial uses a very old version. jotaijs/jotai-tutorial#42

[mindplay-dk]

I don't even recall if I based on that, I might have. anyway, thanks for clearing this up! 😄