docs(adr): record #595 live concurrency evidence #1300
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!1300
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "rigger/595-adr-empirical"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refs #595.
This docs-only PR records the live-runner PREVENT evidence for ADR-0010. It uses the existing disposable frankenbit/cid-probe repository and does not dispatch release infrastructure, invoke rt decide, publish anything, or perform a cut.
The reproducible fixture commit is 1411cacceb2577ae3f62726cfaff915b8da08874. It carried run-rt595-overlap.sh, a minimal workflow with the workflow-level group release-cut-<github.ref> and cancel-in-progress: false, and a no-concurrency runner control. Both grouped invocations targeted main; the control used the same runs-on: go label and ran while the first grouped invocation was active. Forgejo task rows identify runner caymans-fedora (runner id 7; labels go and playwright).
Measured run objects:
Run URLs:
The ADR amendment records the four AC outcomes, the no-fork-failure result and its void condition, exact runner/task evidence, and the separate latency/displacement/promotion boundary. The cid-probe fixture was then removed in cleanup commit 9985d2c5e3f2a36be8c590470d97264465fd7920; the measured commit and run history remain available.
Verification:
Changed file: docs/adr/0010-concurrency-guard-composition.md only.
No-Changelog: ADR evidence only; no runtime code change.
APPROVE —
065df8514aee652603a95edc3a9f6785f0cf594eThe experiment is well designed and I could re-derive its conclusion from the live forge. Docs-only, 29/29 green,
No-Changelogaccepted by the gate.What I verified, rather than read
I went to the instance and re-measured the evidence this amendment records:
Those three creation timestamps are exactly the middle column of your table, to the second. ✅ And they are the numbers the conclusion actually rests on, which makes the finding stronger than the amendment claims for itself:
🔑 The capacity control is what makes this evidence rather than an anecdote. Without run 17, "the second run waited" is equally explained by a busy runner — and the two-second gap on the ungrouped arm closes that off. That is the arm most people would have left out.
📌 Also right, and worth naming because it is the half that usually goes missing: both grouped runs ended
success, so this distinguishes queue from cancel-and-replace — acancel-in-progress: trueinstance would also have produced "the second ran after the first", with the first cancelled. The outcome column is load-bearing, not decoration.🔴 The one thing to fix: the run URLs in the table do not resolve
I checked with a control precisely because a bare 404 could have been my own auth, and the equivalent
release-toolkitURL behaves differently over the identical request. The internal ids you already record are the identifiers that resolve; the run numbers in the links are not.⚠️ This matters more for an ADR than it would anywhere else. The amendment's value is that a future reader can check it — "see the exact run and runner evidence" is the sentence doing that work — and three of the four evidence links in the table are dead on the instance today. The fixture commit links are fine (both 200).
✅ Cheap fix: keep the human URL and add the API path beside it, or cite
id=22170as the primary and the URL as convenience. Nothing else in the amendment changes.Smaller observations
started_at/completed_atcome back null from the API for all three runs, so the first and third columns of your table are not reproducible from that surface — only the task creation times are. Not a defect; your numbers are right and I got them from the task rows. Worth a footnote saying which column is the machine-checkable one, since that is the column a future reader can actually re-run.action_task.runner_idreadback rather than from a label or from the absence of a job log is the correct instrument, and saying so is why I did not have to re-check it.concurrency:VOID condition explicitly unclosed is the right call. One instance's behaviour is not the class, and the amendment says so in the row rather than in a footnote.Land it. The URL fix is worth doing in this PR since it is the amendment's own evidence trail, but it does not block.