Repository navigation
Reduce read requests for recent cleanup histories #612
Description
🤖 Generated by the Agentic Engineer
Outcome
Reduce cleanup's read requests for a dense recent history while preserving the exact complete run set, refusal boundaries and existing shared limits. Keep all search ranges covered; do not assume old history is empty.
Native local measurement
The actual cleanup HTTP client and pagination code from signed core 707c44a0386116d36a122856d0da17ab11479cf4 were exercised against three frozen synthetic workloads at 2026-10-06T00:00:00Z. A private candidate changes only the initial full-history split to separate the last day before ordinary bisection. Both children are still visited.
| Fixed workload | Baseline requests | Candidate requests | Exact returned IDs |
|---|---|---|---|
| 1,001 runs in the last 1,001 complete seconds | 52 | 26 | 1,001 in both |
| 10,001 runs across the last year | 141 | 143 | 10,001 in both |
| 1,001 runs across the whole epoch range | 12 | 13 | 1,001 in both |
The predeclared local thresholds were at least 30% fewer requests for dense recent history and at most 10% additional requests in either other case. The candidate meets those bounded thresholds: 50% fewer, 1.4% more and 8.3% more. Every ID and creation timestamp was checked. These are native local HTTP counts, not live GitHub quota attribution, elapsed-time savings or consumer acceptance. The initial candidate construction was corrected to match the frozen initial-range-only plan before outcome counts were examined; no acceptance threshold changed.
Delivery and acceptance
Land #608 and #610 first, retaining their capped-parent minimum and whole-inventory recovery protections. Then add the bounded search strategy and permanent native HTTP measurement controls, including ancient/dense/sparse histories, day-boundary and early-epoch cases, changed totals, malformed responses, repeated identities, cancellation and exhausted budgets. Preserve the exact retained/deleted run decisions, all ranges, credentials, rate-limit policy and the three read-only native CI callers. Do not increase the partition or wait budget to hide a regression.
Require complete exact-head CI, substantive review, protected merge and merged-source behavior. Record actual hosted request counts with a privacy-safe observer before claiming provider savings. #596 remains open until its separate request attribution and recurrence criteria are satisfied.
Priority: Medium. Effort: Medium. This is a measured follow-up, not a current quota-recovery claim.
Part of #596.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Start date
Target date
Effort
Projects
- StatusShow more project fields✅ Done
Activity
chore: agent-claim #612 nonce=84cff0c6e9702c8498e9d6842df35a73
devantler commentedon Oct 17, 2026
Draft #624 delivers the bounded search strategy: only the capped whole-history search separates its trailing day first, and every other range, including any history shorter than a day, is still halved.
The new permanent native HTTP control runs the actual cleanup client against a frozen synthetic search that serves only the first 1,000 results. Before the change it reproduced this issue's baseline exactly:
A split-point table test covers the trailing-day boundary, a history of exactly one day, one shorter than a day, and nested ranges. The existing capped-minimum, restart, changed-total, malformed, repeated-identity and partition-budget controls all still pass. Four of those fixtures needed their right-half runs moved into the new trailing day.
What remains for this issue: an exact-head external review, merge, and hosted request counts from a privacy-safe observer, which are needed before any provider saving is claimed. I used
Part of #612so this issue stays open for that measurement.perf(cleanup): split the latest day off a capped run history first (#624
devantler commentedon Oct 18, 2026
Board status moved from In Progress to Verifying: the delivery in #624 merged on 2026-10-18 at 00:18 UTC, so nothing is left to build here.
What remains is the post-merge check this issue already names: read the request counts of a real hosted cleanup run that uses the merged source, through a privacy-safe observer, and compare them with the native local measurement above. Until that reading exists, no provider saving is claimed. If the reading cannot be taken yet, this card goes back to Ready with a recorded resume condition rather than waiting here.
chore: agent-claim #612 nonce=390a754993433d4b2fd7cb8161737478
devantler commentedon Oct 18, 2026
The privacy-safe observer this check needs has merged in #642: every successful cleanup now ends with its read and delete request totals, retries included, and nothing else. A local dry-run against this repository read
reads=208 writes=0for 3,563 selected runs.What remains for this card: once a release carrying #642 is consumed, read the totals from one real hosted cleanup run and compare them with the native measurement above. No provider saving is claimed until then.
chore: agent-claim #612 nonce=e7da466ad248c8125d120c3ad74d662d
chore: agent-claim #612 nonce=0617d5cc923ad57f7ab027bd461721bc
devantler commentedon Oct 18, 2026
Verified the remaining hosted request-count check in main CI 39126277075, at signed commit
8d2203af130a8c27b8b98b3d7146f76b5ade7a98, which is exactly the publishedv7.16.2tag. The source includes bounded-search merge #624 (40936d1474df506392d4e8334e8f98615bab6ad4) and observer merge #642 (e39b2bdb2289273bbc079ccad4f63a2fbb2ada0f).All three existing read-only native callers completed successfully and checked out that exact workflow commit:
These are the actual completion receipts (
dry-run=true), using GitHub's real inventory; no workflow history was deleted for this verification. The observer counts HTTP attempts, retries included. This is hosted consumption of the exact released source through its existing native CI callers, not a claim that another repository updated a release pin.The original frozen native comparison remains bounded to its declared workloads: 52→26 reads for dense recent history, 141→143 for year-spread history and 12→13 for epoch-spread history, with identical returned IDs in each pair. The live 211-read observations use a different inventory and are not a before/after pair, so they establish neither a provider savings percentage nor primary-quota attribution.
This completes #612's bounded strategy delivery and hosted observer check. Closing this child does not close #596: its measured request-source attribution, overlapping-activity and pressure-reduction criteria remain open and unchanged.
chore: agent-claim #612 nonce=b2c4e04de9aedbf4f9c97855a1ff7056
chore: agent-claim #612 nonce=cb1c7905c6ce2f07f0aa0909d325b8db