Skip to content

Reduce read requests for recent cleanup histories #612

Closed

Description

@devantler

🤖 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.

Activity

  1. updated Effort Medium and Priority Medium on Oct 15, 2026
  2. moved this to 📥 Backlog in 🌊 Project Boardon Oct 15, 2026
  3. added a commit that references this issue on Oct 17, 2026
  4. moved this from 📥 Backlog to 🏃🏻‍♂️ In Progress in 🌊 Project Boardon Oct 17, 2026
  5. devantler commented on Oct 17, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer (interactive Claude Code session)

    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:

    Workload Baseline With #624 Runs returned
    1,001 runs in the last 1,001 seconds 52 26 all 1,001, each once
    10,001 runs across the last year 141 143 all 10,001, each once
    1,001 runs across the whole epoch 12 13 all 1,001, each once

    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 #612 so this issue stays open for that measurement.

  6. moved this from 🏃🏻‍♂️ In Progress to 📊 Verifying in 🌊 Project Boardon Oct 18, 2026
  7. devantler commented on Oct 18, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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.

  8. added a commit that references this issue on Oct 18, 2026
  9. devantler commented on Oct 18, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    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=0 for 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.

  10. added 2 commits that reference this issue on Oct 18, 2026
  11. devantler commented on Oct 18, 2026

    @devantler
    ContributorAuthor

    🤖 Generated by the Agentic Engineer

    Verified the remaining hosted request-count check in main CI 39126277075, at signed commit 8d2203af130a8c27b8b98b3d7146f76b5ade7a98, which is exactly the published v7.16.2 tag. 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:

    Hosted caller Selected runs Read requests Write requests
    All workflows 3,579 211 0
    Specific pattern 3,049 211 0
    Minimal parameters 3,579 211 0

    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.

  12. added a commit that references this issue on Oct 18, 2026
  13. moved this from 📊 Verifying to ✅ Done in 🌊 Project Boardon Oct 18, 2026
  14. added a commit that references this issue on Oct 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Fields

    Priority

    Medium

    Start date

    None yet

    Target date

    None yet

    Effort

    Medium

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions