Stop announcing an incremental scan the server will refuse - #169
Draft
Ibrahimrahhal wants to merge 1 commit into
Draft
Stop announcing an incremental scan the server will refuse#169Ibrahimrahhal wants to merge 1 commit into
Ibrahimrahhal wants to merge 1 commit into
Conversation
The CLI carries a 5000-path payload guard and lets the server apply the real ceiling, which is right -- INCREMENTAL_SCAN_MAX_FILES is a server setting a deployment can raise and no API reports it, so refusing locally would lose incremental scans that would have worked. What was wrong is what the run said about it. The server refuses a list of 300 or more, so a branch 400 commits' worth of changes away from trunk was told "Incremental scan: 412 files changed since commit abc1234" and then analyzed every file. Past the default ceiling, say that Corgea will most likely scan everything and how to narrow the diff, and leave the promise for the counts that can keep it. Extracted into describe_plan so the boundary is testable without an API. Co-authored-by: ibrahim <ibrahim@corgea.com>
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
2 participants
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.
What
The CLI carries a 5000-path payload guard and lets the server apply the real ceiling. That division is right and stays:
INCREMENTAL_SCAN_MAX_FILESis a server setting a deployment can raise, and no API reports it, so refusing locally would lose incremental scans that would have worked.What was wrong is what the run said about it. The server refuses a changed-file list of 300 or more (
>=, not>), so a branch a few hundred files' worth of changes away from trunk was toldand then had every file analyzed, with nothing in the output to suggest otherwise.
Change
Past the server's default ceiling, say what is likely to happen and how to change it:
Below the ceiling the message is unchanged. The wording is hedged because the ceiling is a server setting this run cannot read — a deployment that raised it will scan incrementally after all, and none of this is worth refusing over.
The message moved into
describe_planso the boundary is testable without an API.Testing
./harness checkpasses: 815 tests, clippy strict, format. Two new unit tests cover the boundary (299 announces, 300 does not) and that a worktree-covering diff still says so.