Long project chat becomes unrecoverable when request exceeds 1048576 characters input limit
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- typescript
Research direction
The report names no files, tests, or entry points. Start by reproducing the oversized project-chat request in Berd 0.6.2 and tracing the context submission and overflow handling; done means the chat has a user-facing recovery path that preserves a concise summary and can continue.
Written by the indexing model from the issue text.
Description
Before filing
- Searched open and closed issues for the exact error text and the numeric limit; no matching Berd issue found.
- Reproduced/observed on the latest Berd release, v0.6.2.
- This report covers one issue: an oversized existing chat request becomes unrecoverable.
What's broken
A long-running project chat can fail with the following error once its accumulated request exceeds 1048576 characters:
Request failed: Internal error: { "details": "Input exceeds the maximum length of 1048576 characters." }
The chat does not provide a clear recovery path such as automatic compaction, truncation of older history, or a way to continue from a compacted summary.
Steps to reproduce
- Launch Berd.
- Open a project chat with substantial prior conversation history.
- Continue using the chat until its accumulated request payload becomes very large.
- Send another message.
- Observe the request failure above.
The affected chat had prior history. The exact model and provider were not recorded.
What I expected to happen
Berd should proactively compact or otherwise reduce the existing chat context before the request exceeds the input limit, or provide a user-facing recovery action that preserves a concise summary and allows the chat to continue.
What actually happened
The request was rejected with the 1,048,576-character limit error. Retrying the same message did not provide a recovery path; starting a new chat was required as a workaround.
How often does it happen?
Once — I have not been able to reproduce it independently.
Berd version
0.6.2
Operating system
macOS (Apple Silicon)
Model and provider
Unknown — not recorded for the affected chat.
Relevant log output
No relevant log output found for the exact error text or numeric limit in the Berd application logs.
Other context
This occurred in a chat inside a Berd project. The error suggests the full accumulated conversation/request context is being submitted before a successful compaction or other overflow recovery step.
- Dominant language
- TypeScript
- Stars
- 928
- Forks
- 121
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 100
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from block/berd
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Saving a custom provider does not set Goose's default provider/model, leaving Goose unavailable Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
danielmiessler/LifeOS#2218 ·