You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 31bdbee
Browse filesBrowse the repository at this point in the historyBrowse files
fix(run-engine): keep a run's execution snapshots in write order across engine clocks
Fix a rare case where a run could stay executing after its task
finished, or a wait could never resume, when the run engine instances
handling the run briefly disagreed on the current time.
The run engine is now correct in the presence of clock skew between its
instances. A run's execution snapshots are written by whichever instance
handles each transition. Both the snapshot's `createdAt`, which the
engine uses to find a run's current snapshot, and its id, which runners
use to tell whether a snapshot is newer, came from that instance's
clock. A snapshot written by an instance whose clock was behind could
therefore sort before the snapshot it replaced. When that happened:
- the runner's attempt completion was rejected;
- the stall check stopped without failing the run;
- a wait could suspend the run with no checkpoint to resume from.
Each new snapshot is now stamped and identified no earlier than 1ms
after the snapshot it follows. A run's snapshots are always ordered in
the order they were written, by `createdAt` and by id, whatever each
instance's clock says, and runners that are already deployed see the
same order as the engine.
Self-hosted deployments that run more than one webapp instance get this
without any configuration change. A new
`run_engine.snapshot.created_at_clamp` histogram records how far ahead
of the local clock a snapshot had to be stamped, which also makes clock
drift between instances visible.
Mono-RevId: b4344abb1441b4c295a1ac77fb5c7e11800f5b67
Fix a rare case where clock skew between run engine instances could leave a run executing after its task finished, or stop a wait from ever resuming. A run's state changes are now always ordered in the order they happened, regardless of clock skew.
0 commit comments