Preserve wider Codex history across dashboard projections - #2915
Preserve wider Codex history across dashboard projections#2915thomaschow19 wants to merge 1 commit into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
clawsweeper
Bot
added
merge-risk: 🚨 compatibility
|
Codex review: needs real behavior proof before merge. Reviewed August 13, 2026, 4:34 PM ET / 20:34 UTC. ClawSweeper reviewWhat this changesThe PR changes Codex cost-cache saving so 7- and 30-day dashboard scans protect the union of the retained cache window and the newly requested scan window during budget enforcement, with regression coverage. Regression provenancePossible regression — probable (reproduction; reviewed change). No predecessor PR is attributed. Merge readiness⛔ Blocked until real behavior proof from a real setup is added - 4 items remain Keep open for normal review: the branch targets the linked cache-retention bug, but the available evidence is synthetic-test-only and local repository inspection failed before current-main and history verification. Likely related people: Whiteknight07 (medium confidence), based on the merged adjacent retention-policy work. Priority: P2 Review scores
Verification
How this fits togetherCodexBar scans local Codex usage into a persisted cost cache, then Usage & Spend requests short dashboard projections from that cache. The save path applies row and byte budgets before the dashboard reads retained daily history. flowchart LR
A[Codex rollout history] --> B[Cost usage scanner]
B --> C[Persisted cost cache]
D[Dashboard scan request] --> E[Retention-window selection]
C --> E
E --> F[Row and byte budget enforcement]
F --> C
C --> G[Usage and Spend dashboard]
Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Preserve the persisted history window as the retention authority, evict only data outside the union window when possible, and document/prove the resulting best-effort cache-size behavior on an upgraded cache. Do we have a high-confidence way to reproduce the issue? Unclear for an independent current-main run: the PR describes a concrete synthetic-store path against v0.49.4, but the sandbox prevented verification of the current code and test path. Is this the best way to solve the issue? Unclear: protecting the retained/requested union matches the reported persistence boundary and adjacent fidelity-first policy, but upgrade cache-size behavior still needs direct evidence. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against daf02ae7a7a4. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
|
Merged via #2920 — your fix was used essentially verbatim (rebased onto current main; only the CHANGELOG conflicted), with Closing this draft as superseded — thank you @thomaschow19 for the precise diagnosis and clean fix, the second one of yours to land this week! |
2 participants
Summary
Reproduction
The regression was reproduced against the v0.49.4 tag using a temporary synthetic store:
No real cache, account data, credentials, or logs were used.
Validation
CODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 swift test --filter 'narrow dashboard windows preserve wider retained cache under byte pressure'make checkmake testpassed groups 1–61, including all cache/scanner/dashboard groups; group 62 hit an unrelated status-menu shared-state failure. Each half of that group passes independently.This is distinct from #2864, which changes Finish now scope and progress rather than retention ownership.
Closes #2914
Refs #2823, #2825, #2861