Jotai v2.7.0+ Derived Atoms Not Recalculating Under Specific Conditions

[yuneco]

Hi dai-shi-san,
Huge thanks to this amazing library.

In Jotai v2.7.0+ (including v2.8.0, latest), there appears to be a case where derived atoms are not being recalculated correctly.

Sample Reproducible Code:

https://codesandbox.io/p/sandbox/jotai-2-7-atom-recalculation-issue-6zz9p8?file=%2Fsrc%2FApp.tsx%3A16%2C61

Sample Code Overview and Expected Output:

We create two primitive atoms (isFooAtom and isBarAtom), two read-only derived atoms (isActive1Atom and isActive2Atom), and one atom for updates (activateAction). Please note that the code is verbose for explanatory purposes.

const isFooAtom = atom(false);
const isBarAtom = atom(false);

const isActive1Atom = atom<boolean>((get) => {
  return get(isFooAtom) && get(isBarAtom);
});

const isActive2Atom = atom<boolean>((get) => {
  return get(isFooAtom) && get(isActive1Atom);
});

const activateAction = atom(undefined, async (get, set) => {
  set(isFooAtom, true);
  set(isBarAtom, true);
});

Since activateAction sets both atoms to true, isActive1Atom and isActive2Atom are expected to be recalculated to true.

However, using the following code does not result in isRunning becoming true even after executing activate():

const App = () => {
  const activate = useSetAtom(activateAction);
  useAtomValue(isActive1Atom);
  const isRunning = useAtomValue(isActive2Atom);

  return (
    <div>
      <button onClick={() => activate()}>Activate</button>
      {isRunning ? "running" : "not running"}
    </div>
  );
};

The issue occurs under the following conditions:

• Jotai version: v2.7.0 or higher (not reproducible in v2.6.5).
• Reading isActive1Atom before isActive2Atom during rendering:

Workaround 1: Comment out the reading of isActive1Atom.

  // useAtomValue(isActive1Atom);
  const isRunning = useAtomValue(isActive2Atom);

Workaround 2: Rearrange the order of reading isActive1Atom.

  const isRunning = useAtomValue(isActive2Atom);
  useAtomValue(isActive1Atom);

This issue can be circumvented in simple cases like this example, but fixing it in a real application is quite challenging. It's not desirable, I think, for atom evaluation results to differ based on the presence or order of useAtomValue, and I would appreciate any insights or advice on this matter.

[dai-shi]

Thanks for reporting. It sounds like a regression with #2396.
We need to create a test. I'm not sure what will be a solution yet (the last resort is to revert it.)

[dai-shi]

#2555 adds a new failing test. (It passes with new store2.ts.)

[dai-shi]

#2555 should fix it.

https://ci.codesandbox.io/status/pmndrs/jotai/pr/2555
Please try it. See "Local Install Instructions" ☝️

[yuneco]

Thank you for addressing the issue promptly!

I have confirmed that the problem has been resolved both in the sample code I provided and in my actual product, I observed that the issue no longer occurs, and the behavior matches that of v2.6.5.