fix(review): keep reviews 14 days and base graphs 30 - #93
Merged
Conversation
The review artifact is the dominant storage cost, being the one kept for weeks, so it drops from 30 days to 14. Base graphs drop from 60 to 30, which still leaves a 16-day window in which a base is reused rather than republished. Modelled at the largest repository we have, that is roughly 3,700 analyses a month within half a Team allowance, against 1,850 before. The renewal threshold moves with the review retention, because it has to: a review references a base by id for its whole life, so a base with less than that remaining is renewed. Ten days against a fourteen-day review would leave a reference dangling for four. A test now fails if the two drift apart, since nothing else would notice. What a pull request open longer than fourteen days loses is the rendered analysis, until someone asks for it again. That costs one incremental over the pull request: the base graph is kept longer and needs no re-analysis. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
CodeBoarding review · analyzing…⏳ CodeBoarding is analyzing this pull request's architecture changes. run 32304167907 · attempt 1 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tightens the three retentions to 14 / 14 / 30 — review artifact, renewal threshold, base graph.
base − threshold)Modelled at the largest repository we have (0.24 MB review, 0.70 MB state, compressed).
Why the threshold moved too
It is not a free parameter. A review artifact references a base by id for its whole life, so the base must have at least that long remaining when the review is written. A 10-day threshold against a 14-day review would leave a reference dangling for four days — precisely what the renewal exists to prevent.
test_the_renewal_threshold_matches_the_review_retentionnow fails if the two drift apart, because nothing else would notice: the result is correct-looking artifacts that quietly point at graphs which expire early.What the shorter review retention costs
A pull request open longer than 14 days loses its rendered analysis until someone asks for it again. That is not a full re-analysis: the base graph is kept 30 days and is fetched rather than recomputed, so
/codeboardingcosts one incremental over the pull request — the same as that pull request's first run.Correctness is unaffected either way; this only decides how long a result stays viewable without re-running.
Why the base did not simply follow to 14
Equal lifetimes make the renewal fire on every run, publishing a base per run instead of per merge base — more storage, not less. 30 against 14 leaves a 16-day reuse window.
test_a_base_outlives_the_reviews_that_reference_itasserts the inequality rather than either literal.🤖 Generated with Claude Code