ReviveBench
An executable study of checkpoint recovery, account binding, stale-worker fencing and side-effect safety.
A credential provider can issue a new token. A workflow runtime can resume a checkpoint. Revive connects those events to the same account, run and pending action.
Every case invokes the repository's real engine, durable SQLite store and HTTP provider client. The provider is a local OAuth fixture, not Microsoft Entra production.
The access token expires and the refresh token is rejected after two completed workflow steps.
The engine parks at the failed step, accepts a new provider grant and completes the original run ID.
The worker that created the checkpoint is replaced before reauthorization completes.
A new engine instance reads SQLite state and resumes without in-memory routing data.
A reauthorization reply returns a different provider subject from the original connection.
The reply is rejected before the one-time recovery capability is consumed.
An old worker wakes up with credential generation 1 after recovery advanced the lease to generation 2.
The durable lease store rejects generation 1 before the worker can execute a step.
An action is marked started, but the worker cannot tell whether the remote mutation committed.
The reconciliation callback confirms the remote action and the mutation function is not called again.
In this harness, Revive preserved the logical run, rejected the wrong account and stale credential generation, survived worker replacement, and reconciled an ambiguous mutation before replay.
The millisecond timings below describe a local process. They are included for reproducibility, not as a production latency claim.
The command rewrites the JSON report from fresh executions. A failed assertion is recorded and returns a non-zero exit code.
npm run bench:revive
python3 -m unittest discover -s sidecar/tests -v