feat: actionable error + APP_MEMORY_MB recommendation when a report exceeds the JSON string cap - #800
Merged
Merged
Conversation
…xceeds the JSON string cap Previously, a report request that tripped Jackson's max-string-length cap (JacksonConfig, #792) fell into GlobalExceptionHandler's catch-all and surfaced to the user as a generic 500 "Report generation failed. Please try again." — no indication of what happened or how to fix it. Backend: GlobalExceptionHandler now handles HttpMessageNotReadableException directly. When the cause is a StreamConstraintsException from the string- length cap, it parses the attempted size out of Jackson's own message and computes a recommended APP_MEMORY_MB by inverting docker-entrypoint.sh's derivation formula (divisor 40, clamp 256) — with a note when even an unlimited memory budget wouldn't help, since the derivation clamps at 256MB regardless. Other malformed-body cases now get a proper 400 instead of falling into the same 500 catch-all. Frontend: the report-download flow reads this structured error (accounting for the request's responseType: 'blob', which applies to error bodies too) and shows an actionable alert with the attempted size and recommended value, instead of the generic failure message. Follows this repo's existing CONTEXT_LENGTH_EXCEEDED pattern for the LLM story generator. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QDyaaPSRNzNXRzJoS794C4
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
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.
Summary
Follow-up to #793/#792. Even with the raised cap, a report can still exceed it (or exceed the pre-raise default on an unmigrated deployment) — and today that fails as a generic 500 "Report generation failed. Please try again.", with no indication of why or what to do.
GlobalExceptionHandler): handlesHttpMessageNotReadableExceptiondirectly instead of letting it fall into the catch-all. When the cause is aStreamConstraintsExceptionfrom the string-length cap, parses the attempted size out of Jackson's own exception message and computes a recommendedAPP_MEMORY_MBby invertingdocker-entrypoint.sh's derivation formula (divisor 40, clamp 256MB) — with a distinct message when the request is past that clamp entirely, since no amount ofAPP_MEMORY_MBwould help there. Other malformed-JSON-body cases (unrelated to this cap) now get a proper 400 instead of the same 500 catch-all they silently fell into before.AnalysisPage.tsx): reads the structured error and shows an actionableAlertwith the attempted size and recommended value, instead of the generic failure text. Had to account for the report request'sresponseType: 'blob'applying to error bodies too — the error JSON comes back as aBlob, not a parsed object, and has to be read out explicitly. Follows this repo's existingCONTEXT_LENGTH_EXCEEDEDpattern (LLM story generator) for structured, actionable error UX.Test plan
GlobalExceptionHandlerTest(new cases): unrelated malformed body → 400; string-length cap → 413 withPAYLOAD_STRING_TOO_LARGE; recommendation math verified against the real reported failure (20,054,016 chars → recommends 1024MB, and independently re-derives that 1024/40 ≥ the attempted size); past-the-hard-ceiling case →recommendedAppMemoryMbis null with the right message.mvn test— 473/474 passing (the one failure is a pre-existing local-environment gap, missingtshark, unrelated to this change).npx tsc --noEmit— clean.npm run build— clean.llm-error.spec.ts) forcing the 413 via route interception, run against a real rebuilt stack in a real browser — alert renders and is visible with the attempted size and recommended value. (This file specifically exists to catch SGDSAlertrenderingnullunder React 19 whendefaultPropsaren't restored — real value in testing the actual DOM here, not just TypeScript types.)/api/v1/files/{fileId}/report— got back413withattemptedSizeMb: 52,recommendedAppMemoryMb: 2560, confirming the real Jackson exception flows through this new handler correctly.🤖 Generated with Claude Code
https://claude.ai/code/session_01QDyaaPSRNzNXRzJoS794C4