fix: recover from 413 Request Entity Too Large via auto-compaction#14707
fix: recover from 413 Request Entity Too Large via auto-compaction#14707nexxeln merged 4 commits intoanomalyco:devfrom
Conversation
When large image attachments cause a 413 error, the session would enter
an infinite retry loop with no recovery path. This fixes four issues:
1. Recognize 413 as context overflow (error.ts)
- Add /request entity too large/i pattern
- Add statusCode === 413 check in parseAPICallError
2. Trigger auto-compaction on context overflow (processor.ts)
- Replace empty TODO with needsCompaction = true
- Fix break-vs-fallthrough bug that caused return undefined
instead of return compact (root cause of infinite loop)
- Publish error notification so user sees what happened
3. Strip media from compaction requests (message-v2.ts, compaction.ts)
- Add stripMedia option to toModelMessages()
- Replace image/PDF file parts with text placeholders
- Strip tool result attachments
- Prevents compaction from hitting the same size limit
4. Handle compaction-itself-overflows (compaction.ts)
- When compaction also returns 413, set error and return stop
- Prevents infinite compaction loop
Additionally, thread an overflow flag through compaction so the
post-compaction continue message explains that media was removed
due to size limits, preventing the model from incorrectly claiming
it lacks vision capabilities.
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
The following comment was made by an LLM, it may be inaccurate: Based on my search, I found several related PRs that address context overflow and compaction issues:
These PRs overlap with the current PR #14707 in addressing context overflow, compaction mechanisms, and loop recovery. You may want to review them to ensure this PR complements rather than conflicts with existing solutions. |
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
- When overflow triggers compaction, exclude the large message from summarization and replay it after, so the model can actually answer it - Skip the isOverflow check during compaction itself — it was treating the compaction's own token usage as another overflow, killing the successful summary - Don't let a failed compaction act as a history boundary — only successful ones should truncate prior context
When the overflow-causing message has large images attached, replaying it raw would just overflow again. Now we replace media parts with text placeholders before replay, same as toModelMessages does with stripMedia. Also extracted a shared isMedia() helper to avoid duplicating the image/pdf check in three places.
|
Hoping this can get merged soon/reviewed by a maintainer. The Copilot Pro service is definitely more aggressive with their 413's compared to OpenAI/Anthropic and it kills your session with no easy way to continue outside of reverting. |
…nomalyco#14707) Co-authored-by: Noam Bressler <noamzbr@gmail.com>
|
#16882 this PR possibly broke the auto compation settings, see related issue |
Issue for this PR
Closes #6574
Type of change
What does this PR do?
provider/error.ts)/request entity too large/itoOVERFLOW_PATTERNSstatusCode === 413catch-all inparseAPICallError()session/processor.ts)ContextOverflowError→needsCompaction = true, publish error notificationelseblock so overflow falls through to cleanup →return "compact"session/message-v2.ts,session/compaction.ts)options?: { stripMedia?: boolean }totoModelMessages()[Attached mime: filename]text placeholders[]toModelMessages(msgs, model, { stripMedia: true })session/compaction.ts)"compact", setsContextOverflowErroron message and returns"stop"session/compaction.ts,session/prompt.ts)overflowflag through compaction flowHow did you verify your code works?
Attached 3 large 4K images → 413 → notification shown → compaction triggered with stripped media → model correctly explains images were too large.
Screenshots / recordings
Screen.Recording.2026-02-22.at.19.23.26.mov
Checklist