alkstore/tasks/release-flake-investigation.md

id, name, status, depends_on, scope, risk, impact, level, tags

id	name	status	depends_on	scope	risk	impact	level	tags
release-flake-investigation	Flake investigation — the pg lock-row trigger fired (dedicated session)	pending		moderate	medium	component	implementation	wave-8 postgres flake-watch

Description

The wave-5 gate's flake-watch flag, carried to this pass (docs/plans/implementation.md §Wave 8; tasks/review-wave-5.md §Notes 6). The watch's trigger has fired: row_lock_ttl_expiry_and_reacquisition failed a second time (the ledger update, 2026-10-10, from the pg-fix-scheduler-fire-wake session — one occurrence in one full sequential pg suite run, failure message lost to output filtering, then green on two subsequent full runs and six focused runs). Per the ledger's own prescription, a dedicated investigative session (instrumentation + focused repro loop) is owed before any postulate-and-fix. The trim row (row_trim_to_semantics, one development-time failure) stays watch-flagged; if it reproduces in this session's loops, it joins the investigation.

The investigation's shape (the ledger's terms, not a postulate-and-fix license):

1. Instrument first: capture the failing row's full assertion output (the prior failures' messages were lost to truncation/filtering — fix that blind spot before anything else: run with --nocapture, or a file-tee'd harness, or a retry-wrapper that preserves output on failure).
2. Focused repro loop: the row under stress — many consecutive runs, varied --test-threads, solo vs concurrent-with-SQLite-column, cold vs warm server — the conditions matrix the two prior occurrences happened under (cold first run; full sequential run). A deliberate slow-clock/lapse-boundary probe (the row's lapse assertions are post-sleep states a slower clock can only delay, never un-lapse — verify that argument by reading the row's actual sleep/tolerance arithmetic against the engine's lock expiry implementation, not by trusting it).
3. Disposition: either (a) reproduced → root-cause analysis → the fix is its own follow-up task (engine bug vs harness-model, called explicitly — the review-002 precedent is that a "flake" was a real engine bug); or (b) not reproduced → the bounded-investigation record (conditions matrix, instrumented output, the read-back of the delay-only argument) with the watch posture updated (keep watching vs instrument permanently vs accept). Both outcomes are acceptable task completions; an uninvestigated shrug is not.

Requires the harness Postgres server (the POC container posture — docs/reviews/003-wave-5-general-review.md §Op note has the env).

Acceptance Criteria

• The output-capture blind spot fixed (a failing run's assertion message is preserved by the recorded procedure)
• The conditions matrix actually run (counts + configurations recorded in Notes)
• The row's sleep/tolerance arithmetic read against the pg lock expiry implementation; the delay-only argument confirmed or corrected
• Disposition recorded: reproduced (→ root cause + follow-up task created) or not-reproduced (→ bounded-investigation record + watch posture updated)
• If the trim row reproduces: it joins the investigation and its outcome is recorded too
• Workspace gates green at session end (any fix is a follow-up task, not a ride-along — unless the root cause is trivially test-side, in which case fix + full gates + Notes)

References

• tasks/review-wave-5.md §Notes 6 (the ledger + the trigger update)
• docs/plans/implementation.md §Wave 8 (the watch carriage)
• docs/reviews/003-wave-5-general-review.md (the concurrence read + the harness-credentials op note)
• docs/reviews/002-wave-4-general-review.md (the flake-was-a-real-bug precedent, F-1)

Notes

To be filled by implementation agent

Summary

To be filled on completion