Conversation
commit_message travels in the query string of the full scan request, so an oversized value overflows the edge proxy's request line limit and the scan fails before reaching the API. The 200-character cap already covered --commit-message, but a run that omitted the flag backfilled the value straight from the checkout's HEAD commit, uncapped, so repositories whose commit messages carry generated release notes could not be scanned at all. Make the cap an invariant of the parsed configuration rather than a step in flag parsing, and apply it to the git-derived value as well. The truncation helper and its limit move to module scope so both sites share one definition. Extract the git setup block out of main_code into apply_git_context so the backfill is reachable from a test. Behavior is unchanged: the same fields are filled in the same order, and a path that is not a repository still sets ignore_commit_files. Note that the API has no length validation on the field. The rejection comes from the proxy in front of it, which reports 413 or 431 depending on which layer answers; the comment now covers both rather than naming one.
…for size Two follow-on safeguards for the same failure, both aimed at CI runs where no one is watching a terminal. Truncation was silent: the notice sat at DEBUG, which a pipeline that does not pass --enable-debug never prints, and the stored value gave no sign it had been clipped. The notice moves to INFO and the value now ends in "...". The 200-character ceiling is unchanged -- the marker replaces the tail rather than extending past it -- so the request line is no larger than before. A request line the proxy refuses comes back as 413, 414 or 431 depending on which limit it checks, carrying the proxy's own response body and nothing about what to change. Those statuses now raise with the cause and the flag to change named, keeping the SDK's original text underneath. None of them were retried before and none are now: the same oversized URL would go back out. Any oversized query parameter is covered, not only the commit message. Buildkite already gets the section markers and the soft_fail hint from _emit_infrastructure_error, which this error reaches like any other API failure, so nothing platform-specific is added here.
|
Follow-up: two safeguards added for CI runs, after confirming the lineage of the original cap. Origin of the cap. The 200-character cap came from CE-196 → #211 → Truncation is no longer silent. The notice moves from DEBUG to INFO and the stored value ends in An oversized request now names its cause. 413, 414 and 431 all mean the proxy refused the request line, and all three previously surfaced as the SDK's generic status-code error carrying the proxy's response body. They now name the cause and the flag to change, with the SDK's original text kept underneath. They were not retried before and are not now, since the same oversized URL would go back out. This covers any oversized query parameter, not only the commit message. Nothing Buildkite-specific was added: One behavior change worth a reviewer's eye: the |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| oversized value is refused by the proxy in front of the API, which reports 413, | ||
| 414 or 431 depending on which limit it checks. Those responses previously | ||
| surfaced as the SDK's generic status-code error carrying the proxy's response | ||
| body. They now name the cause and the flag to change, and remain unretried. |
There was a problem hiding this comment.
CHANGELOG restates the full PR
Low Severity
The 2.9.7 section of CHANGELOG.md retells the incident, the git-backfill gap, the ... marker, the INFO-vs-DEBUG change, and the 413/414/431 handling. That is the PR narrative rather than a few short bullets of what shipped.
Triggered by learned rule: CHANGELOG is user-facing — short bullets only
Reviewed by Cursor Bugbot for commit 392935d. Configure here.
There was a problem hiding this comment.
Fixed in 800836c. The 2.9.7 section is now two bullets covering what a user of a patch release will observe — the cap applies to the value read from the repository, a truncated message ends in ..., and an oversized request names what to shorten. The incident narrative, the git-backfill gap and the INFO-vs-DEBUG reasoning are gone from the changelog; they live in the commit messages and the PR description, which is where history belongs.
The same pass reworded the code comments the entry had been echoing, so each states a present-tense invariant rather than what changed, and both the cap's rationale and the upload path now name the same three statuses instead of two overlapping subsets.
Cut the 2.9.7 section to two bullets: what a user of a patch release needs is the behavior they will see, not the mechanism behind it. Reword the comments the entry was echoing so each states a present-tense invariant, and name the same three statuses in both the cap's rationale and the upload path rather than two overlapping subsets.
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 80a3c96. Configure here.
This branch was successfully deployed
1 participant
What
commit_messageis sent as a query parameter on the full scan request, so an oversized value overflows the edge proxy's request line limit and the scan fails before reaching the API. The 200-character cap already applied to--commit-message, but a run that omitted the flag backfilled the value from the checkout's HEAD commit after config parsing, uncapped. A repository whose HEAD commit message carries generated release notes (~14 KB in the report) could not be scanned at all.The cap is now an invariant of the parsed configuration instead of a step in flag parsing, and it is applied to the git-derived value as well, so every source of
commit_messagelands under the limit.Changes
MAX_COMMIT_MESSAGE_LENGTHand atruncate_commit_messagehelper move to module scope inconfig.py;CliConfig.__post_init__applies the cap to every construction, which covers the flag and config-file paths.socketcli.pyroutes through the same helper.main_codeintoapply_git_context, so the backfill is reachable from a test. Same fields, same order, same handling of a non-repository path.tests/unit/test_commit_message_truncation.py, including a real checkout with a 14 KB commit message.Notes
COMMIT_MESSAGE/BUILDKITE_MESSAGEincore/scm/github.py,CI_COMMIT_MESSAGEincore/scm/gitlab.py) were also named in the report. They are read onto the SCM config objects but never assigned toconfig.commit_messageand never reachFullScanParams, so they are not a live bypass. They stay as-is, holding the raw environment value.Fixes CE-478
Note
Low Risk
Changes are localized to commit-message normalization and full-scan upload error handling; they reduce scan failures without altering auth or scan logic.
Overview
Release 2.9.7 fixes full scans that failed when
commit_messagein the request URL was too long (e.g. huge HEAD commit messages from git backfill).Commit message cap is now enforced everywhere via
truncate_commit_messageandCliConfig.__post_init__(flags, config file, and git-derived values). Over-limit text is shortened to 200 characters with a...suffix and an INFO log. Git setup is refactored intoapply_git_context, which applies the same truncation when fillingcommit_messagefrom the repo.Full-scan upload errors for HTTP 413, 414, or 431 are treated as non-retryable and surfaced with clearer guidance (multipart size vs URL/metadata, including
--commit-message).Tests cover truncation, git backfill, and the new upload error behavior.
Reviewed by Cursor Bugbot for commit 80a3c96. Configure here.