prisma-risk / tsoracle / 26323737302

95%

push

github

fix(driver-paxos): apply-task shutdown uses notify_one (stored permit) (#194)

`StandaloneHost::stop` was calling `apply_shutdown.notify_waiters()`, which only wakes tasks currently inside `.notified().await` and does not store a permit. If the apply task was mid-iteration in its `apply_notify` branch (running `drain_decided_into` then `maybe_snapshot`) when `stop` fired, the notification was silently lost. Because the paxos runner's tick task keeps firing `apply_notify` every couple of milliseconds, the apply task would livelock through the apply-notify branch forever, never observing shutdown — and `host.stop()` is blocked on the apply-handle join with the runner shutdown still ahead of it, so the runner keeps ticking. Permanent livelock.

Swap `notify_waiters()` for `notify_one()`. A permit is stored even when no current waiter exists, so the apply task's next `shutdown.notified()` future consumes it on its first poll and exits the loop.

The race window is the time the apply task spends in `drain_decided_into` + `maybe_snapshot`. Without coverage instrumentation, that window is narrow enough that the race essentially never observes in normal test runs. Under `cargo llvm-cov` (every function call grows counter increments), the window widens enough that the bug triggers reliably — every PR coverage run since 2350e5a (#185) merged hung in `StandaloneHost::stop` for either the snapshot-transfer or partition-churn integration test until the CI run was cancelled.

Adds a `yieldpoint` module that mirrors the structure of `fail-rs` — a registry keyed by `&'static str` plus a `yieldpoint!("name")` macro that, when the `yieldpoints` cargo feature is on, awaits a registered `tokio::sync::Notify` at the call site. The macro expands to `{}` otherwise, so production builds carry zero overhead. The macro is async on purpose: a fail-crate `pause` action would park the worker thread synchronously and wedge tokio's timer driver, which is the shape of bug the origin... (continued)

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

9492 of 9971 relevant lines covered (95.2%)

594277.52 hits per line