Say when a capture was prepared and then dropped - #459
Merged
Conversation
A repository with 815 commits, hooks installed and an index current with HEAD held zero CommitLore records, and doctor reported all ten of its checks ok. Four captures sat in its pending directory, one of them staged with a passing validation and a record ready to attach, all four eight days old. Every step behaved as designed. `capture-stage` stamps expiry five minutes after staging; the commit did not happen inside that window; the prepare-commit-msg gate skipped the record because it had expired; pending-gc protects the staged phase and so never collected the file. The net effect was that the product silently stopped producing records and said nothing. `pending ls` already prints `stale` and `never-collected` on exactly those rows. The information existed. The command people actually run did not carry it, which is #402 and #400's category and the reason this is a doctor change rather than a capture change. The check separates the staged loss from the drafts that never staged, because merging them hides which decisions had a record ready to attach. It names the oldest timestamp so the age is visible without a second command. Limit: the check reads staleness, so a capture whose base commit is still HEAD reports ok even if it has been waiting long enough that nobody remembers preparing it Ruled-out: lengthening the five-minute expiry | a staged record binds to the tree it was prepared for, and attaching it to a different tree is worse than dropping it -- the defect is the silence, not the expiry Ruled-out: letting gc collect expired staged files | that erases the only evidence a capture was ever prepared, and this repository found the defect precisely because the files were still there Warn: a repository that has never captured anything and one whose pending directory was deleted both report ok, so this check cannot distinguish a healthy install from a missing one Blast: local Undo: easy Certainty: firm Verified: six cases -- ok with nothing captured, ok while a capture can still apply, warn naming the staged loss and its wording, staged and never-staged counted separately, no loss claimed when nothing reached staged, and the oldest timestamp present; run against the real repository it reports the one staged loss and three drafts by name Provenance: authored Record-Id: r-doctorpend
CommitLore — record lintTrailers: clean — 1 commit in Active constraints for the paths this PR touchesLimits (102)
Ruled out (236)
Truncated: 86 lines omitted — the comment hit GitHub's 65000 character limit. Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #458. Found in the field, not in a fixture.
What happened
A repository with 815 commits, hooks installed and an index current with HEAD held zero CommitLore records — and
doctorreported all ten of its checksok.Four captures sat in
.git/commitlore/pending/, one staged with a passing validation and a record ready to attach, all four eight days old.Every step behaved as designed
capture-stagestampsexpires_at = staged_at + 5 minutesprepare-commit-msgGate 3 requires unexpired, so it silently skipped the recordpending-gcprotects thestagedphase, so the file is never collectedpending lsalready printsstaleandnever-collectedon exactly those rows. The information existed; the command people actually run did not carry it — #402 and #400's category, and the reason this is a doctor change rather than a capture change.Against the real repository
Staged losses and never-staged drafts are counted separately — merging them hides which decisions had a record ready to attach.
What this deliberately does not change
The five-minute expiry. A staged record binds to the tree it was prepared for, and attaching it to a different tree is worse than dropping it. The defect is the silence, not the expiry.
Nor does gc start collecting expired staged files — that would erase the only evidence a capture was ever prepared, and this defect was found precisely because the files were still there.
Tests
Six new cases, plus the two existing assertions pinning the check list and count updated for the thirteenth check.
test/doctor.test.ts: 57 passed. Dogfood re-run after committing.One fixture note: the pending reader rejects a partial transaction, so the fixture carries its full field set. A shorter fixture made every case pass for the wrong reason — the files were counted as unreadable rather than stale.