Latest Results
reflex-workflow: take a held event when its step is claimed (#7396)
* reflex-workflow: take a held event when its step is claimed
A run holds one event at a time, and a held event stayed in pending_event
until the step running it committed. While that step ran, the row still
showed the wait and its held answer, so deliver refused every new event.
When the step armed the same wait again, as a conversation's turn does, the
refused event was for that next wait, and nothing would deliver it again: the
run sat on the wait until its deadline.
The claim now takes the held event: its step and arguments become the row's
next step, the wait and the held event are cleared, the key is remembered,
and the row is due now. An event delivered while the step runs is then held
for the wait it arms next, the same as one delivered while any other step
runs. A second answer to a wait whose event has not been taken yet is still
refused, so a wait still ends once.
Execution no longer looks for a held event of its own, and settle_event and
abandon lose the parameter that carried one.
Fixes ENG-12995. Regression tests: an engine test delivering while the held
step runs, and the reproduction from the ticket against the conversation
example; both fail without this change.
* Name this PR's news fragment by its number
* reflex-workflow: claim a held event only in its lane, and remember its key at commit
A row holding an event for its wait could still be claimed through its due
next_step, which is the wait's timeout and may be in another lane: the
worker that claimed it then ran the event's step outside the event's lane,
or would have run the timeout the event beats. Such a row is now claimable
only as an event, by a worker serving the event's step.
The claim remembered the event's key as it took it, so a run moved on by
run() before that step ran would refuse a resend of an event it never ran.
The key now travels with the step's arguments and is remembered when the
attempt commits, as before; deliver refuses a resend while it is pending.
Both new tests fail without this change.
* reflex-workflow: ask when work is due by the same conditions a claim takes
Once a row holding an event stopped being claimable through its timeout,
soonest() still counted that timeout's wake_at as this worker's, so a worker
in the timeout's lane saw overdue work it could not take: it looked again
every poll interval and reported an overdue instant to on_idle. And it
treated a held event as answerable by a worker serving either step.
claimable() and soonest() now build from the same two conditions -- a row
whose next_step is this worker's to run on time, and a row holding an event
this worker can run -- so neither can name work the other would not take. Latest Branches
0%
harsh21234i:harsh21234i-fix-app-root-wrap-nesting 0%
benedikt-bartscher:fix/event-callback-upload-spec -7%
harsh21234i:fix/7391-stacked-on-7386 © 2026 CodSpeed Technology