You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Goose sessions using Bedrock fail after viewing more than 5 files. This happens because Bedrock's API has a hard limit of 5 document attachments per request.
To Reproduce
Use Goose with Bedrock provider
View files using the text_editor view command
Try to view more than 5 files in the same session
The session fails with:
{
"message": "You can't include more than 5 documents in a request.Reduce the number of documents and retry your request.","code": "ValidationException",
"aws_request_id": "XXXX-XXXX-XXXX-XXXX"
}
Expected behavior
Session should be able to maintain functionality and context while viewing multiple files, working within or around Bedrock's document limit.
Please provide following information:
OS & Arch: MacOS (affects all platforms)
Interface: CLI
Version: 1.0.5+
Extensions enabled: developer
Provider & Model: AWS Bedrock, anthropic.claude-3-5-sonnet-20241022-v2:0 (but would occur with any Bedrock model)
Additional context
Looking at the Bedrock API docs, this appears to bea core limitation of their API:
"You can include up to five documents. Each document's size must be no more than 4.5 MB."
The issue seems to be in:
crates/goose-mcp/src/developer/mod.rs - text_editor_view function
Currently I manage this in my goosehints by prompting to cat files via the shell tool when looking at more than 5 files. This isn't very robust. When I inevitably hit the issue again, I just open up the session file and manually clean up the history, then prompt to usecat moving forward.
I can think of a couple approaches but I'm not sure which would be best:
Just use regular text content instead of documents for Bedrock
Track document count and clean up old ones or switch to plain text content after 5 documents
Not sure how this works for other providers besides Bedrock and I'm also not totally sure yet what the token usage/cost implications would be of using regular text content vs. document blocks for this.
Happy to attempt a PR with one of the above approaches as well, but very new to this codebase so interested to hear alternative approaches or reasons why either of these proposed solutions are infeasible.
The text was updated successfully, but these errors were encountered:
Is the session erroring out? What would be the downside of failing gracefully to avoid a session breaking error?
Actually perhaps I don't understand the mechanism of failure -- is it 5+ files all at once in a single request to Bedrock? Or 5+ files throughout the course of a session using Bedrock? We use AWS Bedrock ourselves at Block, so I am surprised haven't heard of this issue before from other users at the company
Describe the bug
Goose sessions using Bedrock fail after viewing more than 5 files. This happens because Bedrock's API has a hard limit of 5 document attachments per request.
To Reproduce
view
commandExpected behavior
Session should be able to maintain functionality and context while viewing multiple files, working within or around Bedrock's document limit.
Please provide following information:
Additional context
Looking at the Bedrock API docs, this appears to bea core limitation of their API:
The issue seems to be in:
crates/goose-mcp/src/developer/mod.rs
- text_editor_view functioncrates/goose/src/providers/formats/bedrock.rs
- document handlingCurrently I manage this in my goosehints by prompting to
cat
files via the shell tool when looking at more than 5 files. This isn't very robust. When I inevitably hit the issue again, I just open up the session file and manually clean up the history, then prompt to usecat
moving forward.I can think of a couple approaches but I'm not sure which would be best:
Not sure how this works for other providers besides Bedrock and I'm also not totally sure yet what the token usage/cost implications would be of using regular text content vs. document blocks for this.
Happy to attempt a PR with one of the above approaches as well, but very new to this codebase so interested to hear alternative approaches or reasons why either of these proposed solutions are infeasible.
The text was updated successfully, but these errors were encountered: