What happened
PR #6249 was a Renovate lockfile bump (svelte 5.56.8 → 5.56.9, 3 lines in package-lock.json). Renovate rebased it 4 times over 2 days because main kept advancing and the default config:recommended preset uses rebaseWhen: "behind-base-branch". Each rebase produced a new HEAD SHA, which fired a pull_request_target/synchronize event in the fullsend.yaml workflow, which dispatched a fresh review agent run via review.yml in fullsend-ai/.fullsend. The 5 review runs (31861834071, 31892452164, 31924449278, 31955361732, 31991418368) each ran the full pr-review orchestrator (25 tool calls, 2 sub-agents, ~803K context tokens on claude-opus-4-6) and all returned the same verdict: approve with no findings. Estimated total cost: ~$7.30 for a 3-line lockfile bump.
What could go better
The 4 rebases were unnecessary. The effective diff (svelte version/resolved/integrity lines) was identical across all 5 commits — only the base changed. Since this repo uses a merge queue, the queue itself rebases onto latest main before merging, so pre-merge rebasing by Renovate provides no additional safety. By reducing the rebase frequency at the source, the number of synchronize events (and therefore review dispatches) drops proportionally.
This is complementary to the many existing agent-side proposals (fullsend#4596, #4652, #4401, etc.) that aim to make the review agent skip re-reviews on unchanged diffs. Both approaches are valid, but the Renovate config change is a single-line fix that would take effect immediately while the agent-side solutions remain unimplemented.
Confidence: Medium-high that this would reduce review churn for lockfile-only patch updates. Medium confidence that it won't cause problems for other Renovate PR types — major version bumps or PRs that add/remove dependencies may benefit from rebasing to surface conflicts early. Using Renovate's packageRules to scope the override to lockfile-only or patch-level updates would mitigate this risk. Uncertainty: I haven't verified whether the merge queue configuration actually performs the rebase-before-merge step, but this is standard merge queue behavior.
Proposed change
Add a packageRules entry in the Renovate config (renovate.json or equivalent) that sets rebaseWhen: "conflicted" for lockfile-only patch-level dependency updates. Example:
{
"packageRules": [
{
"matchUpdateTypes": ["patch"],
"matchFileNames": ["package-lock.json"],
"rebaseWhen": "conflicted",
"description": "Only rebase lockfile patch bumps when there are actual conflicts, not whenever main advances"
}
]
}This scopes the change narrowly: only lockfile-only patch updates skip eager rebasing. Minor/major version bumps and PRs that touch package.json continue to rebase normally. The merge queue still rebases before merging, so CI safety is preserved.
Validation criteria
After applying this change, the next 5 Renovate lockfile-only patch PRs on this repo should have at most 1-2 review runs each (down from 4-5), unless they develop actual merge conflicts. Measure by counting review dispatch workflow runs per PR in fullsend-ai/.fullsend. The total review agent cost per lockfile patch PR should drop from ~$7 to ~$1.50.
Generated by retro agent from #6249
What happened
PR #6249 was a Renovate lockfile bump (svelte 5.56.8 → 5.56.9, 3 lines in
package-lock.json). Renovate rebased it 4 times over 2 days becausemainkept advancing and the defaultconfig:recommendedpreset usesrebaseWhen: "behind-base-branch". Each rebase produced a new HEAD SHA, which fired apull_request_target/synchronizeevent in the fullsend.yaml workflow, which dispatched a fresh review agent run via review.yml in fullsend-ai/.fullsend. The 5 review runs (31861834071, 31892452164, 31924449278, 31955361732, 31991418368) each ran the full pr-review orchestrator (25 tool calls, 2 sub-agents, ~803K context tokens on claude-opus-4-6) and all returned the same verdict: approve with no findings. Estimated total cost: ~$7.30 for a 3-line lockfile bump.What could go better
The 4 rebases were unnecessary. The effective diff (svelte version/resolved/integrity lines) was identical across all 5 commits — only the base changed. Since this repo uses a merge queue, the queue itself rebases onto latest
mainbefore merging, so pre-merge rebasing by Renovate provides no additional safety. By reducing the rebase frequency at the source, the number ofsynchronizeevents (and therefore review dispatches) drops proportionally.This is complementary to the many existing agent-side proposals (fullsend#4596, #4652, #4401, etc.) that aim to make the review agent skip re-reviews on unchanged diffs. Both approaches are valid, but the Renovate config change is a single-line fix that would take effect immediately while the agent-side solutions remain unimplemented.
Confidence: Medium-high that this would reduce review churn for lockfile-only patch updates. Medium confidence that it won't cause problems for other Renovate PR types — major version bumps or PRs that add/remove dependencies may benefit from rebasing to surface conflicts early. Using Renovate's
packageRulesto scope the override to lockfile-only or patch-level updates would mitigate this risk. Uncertainty: I haven't verified whether the merge queue configuration actually performs the rebase-before-merge step, but this is standard merge queue behavior.Proposed change
Add a
packageRulesentry in the Renovate config (renovate.jsonor equivalent) that setsrebaseWhen: "conflicted"for lockfile-only patch-level dependency updates. Example:{ "packageRules": [ { "matchUpdateTypes": ["patch"], "matchFileNames": ["package-lock.json"], "rebaseWhen": "conflicted", "description": "Only rebase lockfile patch bumps when there are actual conflicts, not whenever main advances" } ] }This scopes the change narrowly: only lockfile-only patch updates skip eager rebasing. Minor/major version bumps and PRs that touch
package.jsoncontinue to rebase normally. The merge queue still rebases before merging, so CI safety is preserved.Validation criteria
After applying this change, the next 5 Renovate lockfile-only patch PRs on this repo should have at most 1-2 review runs each (down from 4-5), unless they develop actual merge conflicts. Measure by counting review dispatch workflow runs per PR in fullsend-ai/.fullsend. The total review agent cost per lockfile patch PR should drop from ~$7 to ~$1.50.
Generated by retro agent from #6249