docs(agents): correct the pending figure again, and name the endpoint that lies #31
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "docs-pending-precision"
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?
Two corrections to one entry, both mine, and the second is the one that matters past this repo.
The 34 minutes was the wrong interval. It is the delay after
cargofailed, not the timedockerspent pending. There are exactly twodockerrows on287a005c,15:11:32Z pendingand16:00:54Z failure, so it was pending for 49 minutes, of which 34 were post-dependency-failure.And
/commits/{sha}/statusesis the wrong instrument in general. It returns every row ever written, Forgejo's timestamps are second-resolution, and a skipped job writespendingandsuccessin the same second, so any reduction picking one of a tie picks arbitrarily. Four repositories reported strandedpendingstatuses that way today and every one collapsed on/commits/{sha}/status, which dedupes.This case survives, and I checked rather than assumed it. Its two rows are 49 minutes apart rather than tied, which is a property of the data and not of the reduction; the combined endpoint returns
docker=failurefor the same commit; and I verified empirically that my poll'sgroup_by | .[0]selects the newest row, so seeingpendingat16:00:07Zmeans thefailurerow did not exist yet rather than that a tie broke the wrong way.Third correction to one three-line entry in one evening. The claim has now failed for two different reasons — a window nobody justified, and a figure measuring the wrong interval — and neither was visible from inside the reading that produced it.
Two corrections to one entry, both mine. The 34 minutes was the delay after cargo failed, not the time docker spent pending. It has exactly two rows, 15:11:32Z pending and 16:00:54Z failure, so it was pending for 49 minutes of which 34 were after the dependency failed. And the plural statuses endpoint is the wrong instrument in general. It returns every row ever written, Forgejo timestamps are second-resolution, and a skipped job writes pending and success in the same second, so any reduction that picks one of a tie picks arbitrarily. Four repositories reported stranded pending statuses that way today and all four collapsed on /commits/{sha}/status. This case survives because its rows are 49 minutes apart rather than tied, which is a property of the data rather than of the reduction, and the combined endpoint returns the same answer here.