2.0.0-rc.7 | `flush` in action unexpected behavior fixed in 3a5fe8c by not allowing flush in action

[mizulu]

Describe the bug

import { render } from '@solidjs/web';
import { action, createOptimistic, createSignal, flush } from "solid-js";



export default function App() {
  const [signal, setSignal] = createSignal(0);
  const [optimisticValue, setOptimisticValue] = createOptimistic(signal);

 /**
  *  Click "Run once"
    actual: 
      logs:
         0 0 
         0 0 

    expected:
      logs:  
         0 0 
         0 1

  signal used in an optimistic signal source, prevents flushing of the signal 
  in an "action"
  */

  const run = action(function* () {
    console.log(optimisticValue(), signal())
    setSignal(1);
    flush()
    console.log(optimisticValue(), signal())
  });



  return (
    <main>
      <button onClick={run}>Run once</button>
      <p>Value: {optimisticValue()}</p>
    </main>
  );
}

if (typeof document !== 'undefined') {
  render(() => <App />, document.getElementById('root')!);
}

Your Example Website or App

https://s.olid.uk/id/ILIMhE-cRXeISRjlRaxXwQ

Steps to Reproduce the Bug or Issue

see playground

Expected behavior

probably not what we are getting.

Screenshots or Videos

No response

Platform

.

Additional context

issue might share common root cause with #3330
or not.

https://s.olid.uk/id/RmxCWTx3RXmTFMsAb5b58g

edit: verdict is that the bug is allowing flush in action, and it is expected that no flush should be allowed in an action.
as shown in the followup comment below

[mizulu]

A flush in the beginning of the action
will fix the flush after the set. and will log what is expected after the set.

https://s.olid.uk/id/i7euwCG1QUaxnDknMaLy0g

Logs:

0 0 
1 1

instead of

0 0 
0 0 

  const run = action(function* () {
    flush() // <--------------- Fixes the flush after set.
    console.log(optimisticValue(), signal())
    
    setSignal(1);
    flush()


    console.log(optimisticValue(), signal())
    yield new Promise(r => setTimeout(r, 1000))
    console.log("done")
  });

---

confirmed this likely has the same root cause as #3330
because the same fix here, fixes the issue of #3330 https://s.olid.uk/id/rAsxdJLESOCTZHQUWcNuew

[ryansolid]

Thanks for the clear reproduction. This is working as designed on the read side, and the part that looked like it worked was a real bug — now fixed in 3a5fe8c.

Why 0 0 twice is correct. An action body runs inside a transaction. Every write in it (setSignal(1)) is held in that transaction until the action settles, then committed atomically; that is the whole point of action — intermediate state never leaks to the screen. Imperative reads inside the body (signal(), optimisticValue(), called with no tracking context) return the committed value, so they see 0 until the action completes. This is not optimistic-specific: swap createOptimistic for a plain signal and you get the same two 0 0 lines. Reads in an action body seeing the pre-action world is the semantics, not staleness to work around.

Why flush() didn't help, and what it was actually doing. flush() can't reveal held writes — they aren't scheduled, they're parked. But its drain loop only exits once the ambient transition is cleared, so calling it inside the body parked the transaction mid-step: every write that followed the flush() in the same body landed as a plain, committed write, visible on screen before the action finished. That is why a "leading flush()" appeared to fix things — it was escaping the transaction. The same applies to the workaround in #3330; that issue stays open on its own merits.

What changed. flush() inside an action body is now refused: DEV throws FLUSH_IN_ACTION with an explanation, prod skips the drain (so nothing detaches). If you need to observe the result of an action, read after it resolves (await run()), or put the read in a reactive scope (JSX/memo/effect), which sees the transition's value once it commits.

Closing as by-design for the read behaviour; the leak the workaround relied on is fixed.

— Claude via Cursor

[mizulu]

@ryansolid / Claude

for the future, when you close a ticket with changes based on that ticker discoveries, you should not mark it as
"Not Planned"

you should close it with the associated fix you already linked
3a5fe8c

Not Planned is misleading, and make us assume that there was no bug or issues reported in this issue.
we can clearly see a fix derived from the finding of this ticket.

we can simply adapt the issue description to that remained bug.
which is the flush in action bug.

[ryansolid]

Fair point, thanks — reclosing as completed. The read semantics in the original report are by design, but the leaking in-body flush() this issue surfaced was a real bug, fixed in 3a5fe8c.

— Claude via Cursor