Repository navigation
emrg: an absent origin's row does not say whether this ledger could have held the handle #1953
Description
What is wrong
scripts/check-issue-links.py classifies an absent rant origin as never held or may have been
pruned from the ledger's retention rule, and both wordings stop there. Neither carries a fact the
ledger in hand already has: is the citation newer than every record this ledger ranks? When it
is, nothing here ranked above the handle, no retention rule could have displaced it, and the store
had not received it by its own last write — which is what turns the row from "go find the record"
into "this chain cannot be walked from here".
That distinction is not hypothetical, and the live queue holds one right now. Measured on master
55407aa5:
#1949 issue ORIGIN-UNRESOLVED - emrg: the span finder's newline clause is load-bearing and unpinned
the origin line names rant `2026-10-09T02:29:58.871666+08:00`, which the rant ledger
(/Users/argszero/.emrg/rants.jsonl) does not hold - the ledger holds 0 completed rant(s) at or
after this instant, fewer than the 10 `submit_rant cleanup` keeps, so a rant dated at this
instant would still be in the ledger whatever its status - the retention rule cannot explain
the absence, and there is nothing here to copy: the handle names no record this ledger ever
held. Re-derive the origin from whatever submitted the rant (the session or command that did),
or record the issue as carrying a chain that cannot be walked
The cited instant postdates every record in that ledger (its newest is
2026-10-09T00:59:56.097218+08:00), so the store had not received the handle by its last write —
and the row says none of that. A rant timestamp is host-local, so the record may well exist, in the
ledger of the machine that wrote it: scripts/check-rant-citations.py's own docstring records a
reporter measuring 0 of 24 citations resolving on a second host (issue #1252).
Why it matters
The remedy the row prints has no end state here. Re-derive the origin from whatever submitted the rant presumes the handle is reachable from this machine, and when the citation is newer than
everything the ledger holds it is not: the only place it can be walked is wherever the issue was
opened. A reader following the row's advice looks for a copy that was never in this store.
What fixing it looks like
- The row names the newest record the ledger ranks — by the same
completed or timestampkey
cleanup_rantssorts by, not by the submission instant alone, which can name an instant the
store itself ranks lower — and says whether the citation is newer than it. - The "older than the citation" sentence is printed only when it is measured true; a citation
that is not newer gets the wording that matches (the store has received records at least as
recent), and a ledger with nothing orderable says the question cannot be dated here — never
"older", which would make the absent row its own evidence. - Neither branch offers a copy, and the remedy names the machine the handle can be walked on. The
reading stays a local file read; it never becomes a network call.
Activity
how2how2how2-arch commentedon Oct 8, 2026
Handled by #1954