prisma-risk / tsoracle / 26377743300

95%

Build Type

push

github

Committed by web-flow

Commit Message

fix(driver-paxos): bound StandaloneHost barrier waits with a deadline and apply-task liveness (#364)

current_high_water and submit_advance appended a Barrier and then looped on
the apply-state notifier with no deadline, cancellation, or liveness check.
If the apply task died (panic) or the barrier never decided (quorum loss,
lost leadership), the await parked forever — a liveness hazard that surfaced
as a stuck server (the fence and window-extension paths call these through
the driver) rather than a clean, retryable error.

Bound both waits three ways via a shared await_barrier helper:

- Deadline: a configurable barrier_timeout (StandaloneHostBuilder, default 5s)
  wraps the wait; on elapse it returns a retryable ConsensusError::TransientDriver.
  The default is generous relative to the tick cadence, so it fires only when
  the barrier genuinely cannot make progress.
- Apply-task liveness: ApplyEngine now carries a tri-state signal
  (NeverSpawned -> Alive -> Dead). spawn marks it Alive and installs a
  drop-guard in the task that flips it to Dead and wakes parked waiters on any
  exit (shutdown break, panic unwind, or abort). A waiter that sees Dead fails
  fast with a non-retryable ConsensusError::PermanentDriver instead of waiting
  out the whole deadline. "NeverSpawned" is deliberately not treated as death,
  so the synchronous stepping path (which folds barriers via apply_once, no
  task) is unaffected.

Error classification follows the ConsensusError contract: a stalled barrier is
most likely transient (the caller's epoch fence surfaces a genuine leadership
loss separately), while a dead apply task will not recover by retrying.

Tests run under tokio virtual time: a barrier that never applies times out as
TransientDriver, and a barrier read after the apply task is stopped fails fast
as PermanentDriver. Mutation-verified (disabling the death-check makes the
death test observe the timeout instead).

Closes #354

Coverage Stats

46 of 46 new or added lines in 2 files covered. (100.0%)

2 existing lines in 1 file now uncovered.

11758 of 12398 relevant lines covered (94.84%)

419499.91 hits per line