Malformed Bedrock streams can fail application streams or consume unbounded memory #19812

Describe the bug

The AWS SDK 2.x Bedrock streaming wrappers parse response events for telemetry before forwarding them to the application's subscriber. There are a few different flavors of the parser for ConverseStream and InvokeModelWithResponseStream, and they all assume that events arrive in the expected order.

For example, a text delta before its message-start event dereferences a null currentText, and a tool delta before its content-block-start event dereferences a null builder. This is visible in the Converse handler, with equivalent assumptions in the Nova and Anthropic handlers.

The same handlers retain text, tool arguments, completed tools, and stop reasons without size or count limits. Tool arguments are accumulated even when captureMessageContent is false, although the arguments are omitted from telemetry in that mode. An input_json_delta sequence without a matching tool-start event can also grow currentInputJson indefinitely because the stop handler only clears it when currentTool is non-null.

It is not common, but definitely possible for a service, proxy, test double, or future SDK/model behavior to produce a missing, duplicated, out-of-order, or abnormally long sequence. Instrumentation should not turn that into an application-visible stream failure or unbounded heap growth.

Steps to reproduce

Feed any of these sequences through the wrapped publisher:

1. With message-content capture enabled, send a text ContentBlockDeltaEvent before MessageStartEvent (or the equivalent Nova/Anthropic JSON events).
2. Send a tool-use delta before ContentBlockStartEvent.
3. Send an arbitrarily long sequence of tool-input deltas, including with message-content capture disabled.
4. For Anthropic, send input_json_delta events without a preceding content_block_start, so currentTool remains null and the accumulated JSON is never cleared.

The publisher mapping calls handleEvent(event) before returning the event to the delegate, so a telemetry exception prevents the application subscriber from receiving that event: BedrockRuntimeImpl.java#L1198-L1204

Expected behavior

Malformed or excessive telemetry input should be ignored or truncated without changing the delegate publisher's behavior. Stream state should validate transitions, have explicit size/count limits, and be cleared consistently at message, block, and stream boundaries.

Actual behavior

Missing or out-of-order start events can throw from telemetry parsing before the delegate sees the event. Long or repeated event sequences can retain memory for the lifetime of the stream, including content that is not configured for capture.

Javaagent or library instrumentation version

Current main at 200ed04011fef82dbcbab4905471571654363c7c.

Environment

JDK: any
OS: any

Additional context

Related but distinct reports:

• converseStream fails when an LLM tool call has empty input (AWS SDK instrumentation) #18704 covered an empty tool-argument parse failure and was fixed by Fix NPE in Bedrock converseStream when tool use has empty arguments #18783.
• BedrockRuntimeAsyncClient streaming wrappers close Scope too early (can break/cancel stream) #16197 concerned context/scope lifetime around the asynchronous Bedrock stream.

Neither covers transition validation, bounded retained state, or isolating telemetry parsing failures from the application subscriber.

Further note: this issue was found and the description authored by codex, under human review. I (the human) have substantially validated the finding - there is a real set of instrumentation issues here with malformed/out-of-order streams.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}