fix(deploy): converge hdb_deployment terminal status on peers - #1171
Conversation
The deploy lifecycle writes the hdb_deployment row ~10 times within a few hundred ms (create, payload ingest, phase flushes, per-peer results, finish). These replicate to peers; on a loaded peer the rapid same-key writes can commit out of order, where an older full update reverts the terminal `success` write — the peer row stays stuck at `replicating` and never converges (#1170). Add DeploymentRecorder.seal(), called before the replicate phase: scheduleFlush() stops issuing puts (state accumulates in memory) and finish() performs a single terminal write, isolating it from the concurrent same-key burst so the receiver converges. The ProgressEmitter still emits live SSE events; only the origin's get_deployment polling view skips the transient `replicating` status and incremental peer_results during the final phase. Mitigation pending #1170. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
Reviewed; no blockers found. |
|
Marking ready for review. ✅ Verification: the actual failing test ( Note on red CI: the only remaining failure is — Claude (Opus 4.x) |
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
2 participants
Summary
The deploy lifecycle writes the
hdb_deploymentrow ~10 times within a few hundred ms (create, payload ingest, phase flushes, per-peer results,finish()). These replicate to peers; on a loaded peer the rapid same-key writes can commit out of order, where an older full update reverts the terminalsuccesswrite — the peer row stays stuck atreplicatingand never converges.This adds
DeploymentRecorder.seal(), called before the replicate phase:scheduleFlush()stops issuing puts (state accumulates in memory) andfinish()performs a single terminal write, isolating it from the concurrent same-key burst so the receiver converges.Purpose
Fixes the intermittently-failing harper-pro integration test
deployTrackingReplication.test.mjs("hdb_deployment row replicates to peers" —saw replicating). It is pre-existing on harper-promain(failed on Node v22/v24 shard 4; v26 happened to pass), not introduced by any feature branch — it's a timing-dependent replication race.This is a mitigation. The underlying defect is in core replication (an out-of-order full update can revert a newer record): #1170, fixed separately.
Where to look
components/deploymentRecorder.ts—sealedflag +seal();scheduleFlush()early-returns when sealed.components/operations.js—recorder?.seal()before the replicate phase.Tradeoff (deliberate)
The origin's
get_deploymentpolling view no longer shows the transientreplicatingstatus or incrementalpeer_resultsduring the final phase. Live SSE tailing is unaffected (the emitter still emits in real time). Once #1170 lands, this seal can be removed to restore incrementalpeer_resultspersistence.Verification
seal());test:unit:mainshows no regressions.corepointer to this branch (the test only runs in harper-pro CI).Cross-model review: Codex (no issues) + Gemini/AntiGravity (correct; two low-severity suggestions — guard the unused
transitionPhase, resetdirtyinfinish()— intentionally skipped as YAGNI sincefinishedalready gates further writes).🤖 Generated by Claude (Opus 4.x) per the Harper engineering DLC.