The 0.3.0 driver probes strictly sequentially (one outstanding candidate). For SelectionPolicy::FoldAll that makes a full sweep serial — worst case N × timeout for a lineage of N when newer generations are gone, vs ~one timeout for a concurrent sweep.
Delta today ships a CONCURRENT sweep with interim re-PUTs as generations arrive (operations.rs::fire_legacy_contract_migrations + reconcile_into), so adopting the sequential driver as-is would regress: (a) worst-case recovery latency (~N×12s vs ~12s), (b) interim visibility (pages appear as generations arrive), (c) mid-sweep durability of partial progress (bounded — the no-delete invariant keeps old keys probeable and Delta re-probes on next load).
Documented as an open decision in contract_probe's docs. Options, to be decided against Delta's real constraints AT its adoption phase — not speculatively:
- Concurrent-sweep driver mode (multiple outstanding candidates + per-candidate events; requires revisiting the single-shot correlation semantics — do not widen silently).
- Delta accepts sequential + one-final-PUT, documented as a known trade.
- Hybrid: sequential drive with a concurrent prefetch layer in the app's IO adapter (decisions stay sequential; network overlap app-side).
Also relevant for that phase: porting Delta's real reconcile fixtures into the crate's regression suite (G1.9 follow-up from the PR #5 review), and the G1.6 merge_fn widening for non-ComposableState apps.
Refs: PR #5 review thread (adoptability lens), freenet-core#2776, the Delta behavioral spec in the workstream transcript.
[AI-assisted - Claude]
The 0.3.0 driver probes strictly sequentially (one outstanding candidate). For
SelectionPolicy::FoldAllthat makes a full sweep serial — worst case N × timeout for a lineage of N when newer generations are gone, vs ~one timeout for a concurrent sweep.Delta today ships a CONCURRENT sweep with interim re-PUTs as generations arrive (
operations.rs::fire_legacy_contract_migrations+reconcile_into), so adopting the sequential driver as-is would regress: (a) worst-case recovery latency (~N×12s vs ~12s), (b) interim visibility (pages appear as generations arrive), (c) mid-sweep durability of partial progress (bounded — the no-delete invariant keeps old keys probeable and Delta re-probes on next load).Documented as an open decision in
contract_probe's docs. Options, to be decided against Delta's real constraints AT its adoption phase — not speculatively:Also relevant for that phase: porting Delta's real reconcile fixtures into the crate's regression suite (G1.9 follow-up from the PR #5 review), and the G1.6
merge_fnwidening for non-ComposableStateapps.Refs: PR #5 review thread (adoptability lens), freenet-core#2776, the Delta behavioral spec in the workstream transcript.
[AI-assisted - Claude]