[BUG] Bedrock prompt-too-long ValidationException is not mapped to ContextWindowOverflowException

[mikegc-aws]

Checks

• I have updated to the lastest minor and patch version of Strands
• I have checked the documentation and this is not expected behavior
• I have searched ./issues and there are no duplicates of my issue

Strands Version

1.25.0

Python Version

3.14.1

Operating System

macOS 26.3.1

Installation Method

other

Steps to Reproduce

1. Create a Strands agent using the Bedrock model provider (ConverseStream API) — e.g., Claude Opus 4.6
2. Equip the agent with tools that produce large outputs (e.g., AgentCore browser tool — page navigation, page inspection)
3. Run an agent session where accumulated tool results push conversation context past the model's token limit (200k for Claude)
4. Observe the error when the next ConverseStream call is made

Expected Behavior

The Bedrock model provider should detect a ValidationException with a "prompt is too long" message and raise ContextWindowOverflowException. This would allow conversation managers (e.g., SlidingWindowConversationManager) to catch the exception, call reduce_context(), trim conversation history, and retry automatically — which is how other model providers already handle context overflow.

Actual Behavior

The botocore.errorfactory.ValidationException propagates up as-is and gets wrapped as a generic EventLoopException. The SlidingWindowConversationManager overflow handling never fires because it's looking for ContextWindowOverflowException, not ValidationException. The agent fails hard instead of gracefully trimming context and retrying.

Error message:botocore.errorfactory.ValidationException: prompt is too long: 248369 tokens > 200000 maximum

Additional Context

1. This is a widespread issue — multiple teams and users are hitting the same ValidationException on context overflow with Bedrock across #bedrock-interest, #wasabi-interest, #pippin-interest, #kiro-cli-internal-software-builders, #strands-agents-interest, and #bedrock-agents-interest. Users are forced to manually clear context or start new sessions.
2. The Kiro CLI team shipped a fix for their version of this issue in CLI v1.26.2, suggesting the pattern is well-understood.
3. Bedrock Agents (managed) also surfaces this as a validationException through InvokeAgent, so this may affect multiple integration paths.

Possible Solution

In the Bedrock model provider implementation, detect when:

1. The exception type is a Bedrock ValidationException (via botocore)
2. The error message contains "prompt is too long" (or similar pattern like "Input is too long")

→ Raise ContextWindowOverflowException instead of letting the ValidationException propagate.

This aligns Bedrock's behavior with other providers where token overflow is already surfaced as ContextWindowOverflowException, enabling existing conversation manager retry logic to work correctly.

Related Issues

No response

[shivamnegi1705]

Hi @mikegc-aws , I did a deeper dive into this issue to understand the code flow, and this is what I understood.

In bedrock.py, there's a constant that lists known overflow error message patterns:

BEDROCK_CONTEXT_WINDOW_OVERFLOW_MESSAGES = [
    "Input is too long for requested model",
    "input length and `max_tokens` exceed context limit",
    "too many total text bytes",
    "prompt is too long",  # <-- this was added by PR #1663
]

The _stream method catches ClientError (which ValidationException is a subclass of) and checks if the error message contains any of these patterns. If it matches, it raises ContextWindowOverflowException instead:

except ClientError as e:
    error_message = str(e)
    # ...
    if any(overflow_message in error_message for overflow_message in BEDROCK_CONTEXT_WINDOW_OVERFLOW_MESSAGES):
        raise ContextWindowOverflowException(e) from e

This lets the agent's retry flow in agent.py kick in:

except ContextWindowOverflowException as e:
    self.conversation_manager.reduce_context(self, e=e)
    # retry the event loop cycle

From what I can see, this handling has already been merged into main via PR #1663

Please let me know if I have misunderstood any part of the flow or if there are additional cases that this change does not cover.