Native rewrites every open wait position on each reorder (Workflow #899 parity) #783

Activity

1. rmcdaniel commented on Oct 26, 2026

   

   rmcdaniel

   on Oct 26, 2026

   MemberAuthor

   More actions

   Correction to this issue's parity section, after reading Workflow PR #941 at c608431d.

   What #941 stores. RunWaitProjector::chronologicalPositions ranks every retained wait of the run, whatever its status, by opened_at in milliseconds (null last), then wait_id. WorkflowRunWait::scopeInDisplayOrder applies the status ranking only when reading.

   What native stores today. order_open_waits ranks only open waits. A resolved or cancelled wait keeps whatever ordinal it last had as an open wait, so resolved rows can share positions or fall out of chronological order. Native's own reads aren't affected, because run_observation_waits selects only open waits and both orderings rank open waits the same way. A PHP reader of a native-written database would see resolved waits out of order until PHP projects the run again. So the line "native already stores chronological ordinals" holds for open waits only.

   Fix on branch fix/783-native-wait-position-churn

   • Native stores #941's ordinal over all retained waits, using the same millisecond and wait_id ordering it already used for open waits.
   • One query per page ranks the run's waits in the database (ROW_NUMBER()) and returns only the rows whose stored position differs. Native then updates those rows by primary key.
   • Resolving a wait no longer moves any other wait, so most transitions write no positions. A new wait is normally inserted at its final ordinal (sequence - 1), so it writes nothing either.
   • Ranking stays a plain consistent-read SELECT followed by primary-key updates. That keeps MySQL from taking the gap locks a multi-table UPDATE … JOIN would take.
   • If a row still differs after it was written in the same pass, the transition fails with wait_position_not_applied instead of looping.

   Test (rust/tests/execution/wait_positions.rs, run on SQLite, PostgreSQL, MySQL and MariaDB)

   • Retained clocks are set against wait_id order.
   • Resolving a wait writes no positions. The open-only ordinal would move one timer and rewrite another in place.
   • A new wait is the only row that may be written.
   • Positions written by another projector converge, and only those rows are written.

   Trigger logging covers both cases: SQLite and PostgreSQL log every write of the column, including unchanged rewrites; MySQL and MariaDB log value changes.

   No HTTP, protocol or fixture shape changes. Activation follows the queue: #774, then the #773 successor.

   🤖 Generated with Claude Code
2. rmcdaniel

   closed this as completedin #790on Oct 26, 2026