BedrockRuntimeAsyncClient.invokeModelWithResponseStream swallowed the exception that being throw by Visitor

Describe the bug

Issue: the exception that being throw within the Visitor is being swallowed by the BedrockRuntimeAsyncClient.invokeModelWithResponseStream

Expected Behavior

The exception should be throw by CompletableFuture<Void> and wrapped by CompletionException

Current Behavior

The reply from the base model is being cut while the main process is closed with exit code 0 which misleading for our use case.

Reproduction Steps

Code Snippet:

internal object BedrockRuntime {
    ...
    fun <T> invokeModelWithResponseStream(modelId: String, body: Any, type: Class<T>, consumer: Consumer<T>) {
        val request = InvokeModelWithResponseStreamRequest.builder()
            .modelId(modelId)
            .body(SdkBytes.fromUtf8String(objectMapper.writeValueAsString(body)))
            .contentType(JSON_MEDIA_TYPE)
            .accept(JSON_MEDIA_TYPE)
            .build()
        val visitor = InvokeModelWithResponseStreamResponseHandler.Visitor.builder()
            .onChunk {
                val payload = it
                    .bytes()
                    .asUtf8String()
                val response = objectMapper.readValue(payload, type)
                consumer.accept(response)
            }
            .build()
        val handler = InvokeModelWithResponseStreamResponseHandler.builder()
            .subscriber(visitor)
            .build()
        try {
            asyncClient.invokeModelWithResponseStream(request, handler)
                .join()
        } catch (exception: Exception) {
            exception.printStackTrace()
        }
    }
    ...
}
...
object Application {
    @JvmStatic
    fun main(args: Array<String>) {
        ...
        var counter = 0
        BedrockRuntime.invokeModelWithResponseStream(CLAUDE_MODEL_ID, request, ClaudeBodyResponse::class.java) {
            counter++
            print(it.completion)
            if (counter > 10) {
                throw RuntimeException("TEST")
            }
        }
        ...
    }
}

Output:

 Berikut adalah beberapa tips unt
Process finished with exit code 0

Possible Solution

No response

Additional Information/Context

Kotlin Version: 1.9.22

AWS Java SDK version used

2.24.1

JDK version used

openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode)

Operating System and version

macOS Sonoma Version 14.3.1

Facing the same issue. Below is Java code to reproduce:

import software.amazon.awssdk.auth.credentials.*;
import software.amazon.awssdk.regions.*;
import software.amazon.awssdk.services.bedrockruntime.*;
import software.amazon.awssdk.services.bedrockruntime.model.*;

import java.util.*;
import java.util.concurrent.*;
import java.util.concurrent.atomic.*;

import static java.lang.System.*;
import static software.amazon.awssdk.services.bedrockruntime.model.ContentBlock.*;
import static software.amazon.awssdk.services.bedrockruntime.model.ConversationRole.*;

public class BedrockConverseStreamTest {

    public static void main(String[] args) throws Throwable {

        var msgCounter = new AtomicInteger(0);

        var client = BedrockRuntimeAsyncClient.builder().credentialsProvider(DefaultCredentialsProvider.create()).region(Region.US_WEST_2).build();

        var request = ConverseStreamRequest.builder()
                .modelId("anthropic.claude-3-5-sonnet-20240620-v1:0")
                .messages(List.of(Message.builder()
                        .role(USER)
                        .content(List.of(fromText("Say: Hello from Bedrock streaming")))
                        .build()))
                .build();

        CompletableFuture<Void> future = client.converseStream(
                request,
                ConverseStreamResponseHandler.builder()
                        .onResponse(resp -> out.println("📨 onResponse called::" + resp.toString()))
                        .onError(err -> err.printStackTrace())
                        .onComplete(() -> out.println("onComplete called"))
                        .subscriber(new ConverseStreamResponseHandler.Visitor() {
                            @Override
                            public void visitDefault(ConverseStreamOutput e) {
                                out.println(msgCounter + "::On Visit::count:" + e.toString());

                                // inject poison pill at random on visit call let say 13th on visit.
                                if (msgCounter.incrementAndGet() == 13) throw new RuntimeException("auuch");
                            }
                        })
                        .build());

        future.get(150, TimeUnit.SECONDS); // block until stream done (tune as needed)
    }
}

Expected the onError to be called

Its been long this issue is open

Yes, it's been a long time with no updates, I apologize for that.

We see the issue, the call should complete exceptionally in this case, We'll investigate a way to surface the exceptions.

We are hitting this at production scale on ConverseStream, and can add three things to the report: this happens without the developer throwing, we have wire-level proof of the mechanism, and AWS support has independently confirmed the service-side half.

The swallow does not require the developer to throw from their own Visitor. Our visitor callbacks are individually wrapped in a catch, yet we still see the failure signature about 150 times per night: SequentialSubscriber's cancel fires between one decoded event and its delivery, so the throwable appears to originate inside the SDK's own delivery pipeline (flatMapIterable chain or demand handling), not user code.
HTTP/2 frame captures show the full consequence chain: the catch in SequentialSubscriber.onNext cancels the h2 stream (RST_STREAM errorCode=8 CANCEL), remaining events including messageStop and metadata are discarded, EventStreamAsyncResponseTransformer.handleOnStreamCancel completes the operation future successfully, and the cause is lost in the CompletableFuture that DefaultEventStreamResponseHandlerBuilder.subscriber(Consumer) constructs inline and discards. From the caller's perspective the operation succeeded and the response is simply truncated.
We opened an AWS support case on the Bedrock side and asked them to check their send-side records for the affected request IDs. They confirmed independently: on every failing call they checked, Bedrock generated and transmitted the complete response, terminal frames included, with no network error. That rules out a service-side or network-side cause and narrows this to the SDK delivery path. Happy to put the SDK team in touch with that case if useful.

Environment: aws-sdk-java 2.52.1, NettyNio, Bedrock ConverseStream with tools, anthropic.claude-sonnet-4-6, ECS Fargate. Failing responses share one shape: a tool_use content block whose entire streamed input is empty (one delta with an empty string, then
contentBlockStop), under concurrent load on a shared HTTP/2 connection. Redacted frame logs for a failing and a healthy stream on the same connection are available on request.

Beyond surfacing the exception, please also make sure the operation future does not complete successfully when the stream was cancelled by a delivery failure; that combination is what made this undiagnosable for weeks.

Navigation Menu

Repository navigation

BedrockRuntimeAsyncClient.invokeModelWithResponseStream swallowed the exception that being throw by Visitor #4929

Describe the bug

Expected Behavior

Current Behavior

Reproduction Steps

Possible Solution

Additional Information/Context

AWS Java SDK version used

JDK version used

Operating System and version

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

BedrockRuntimeAsyncClient.invokeModelWithResponseStream swallowed the exception that being throw by Visitor #4929

Description

Describe the bug

Expected Behavior

Current Behavior

Reproduction Steps

Possible Solution

Additional Information/Context

AWS Java SDK version used

JDK version used

Operating System and version

Activity

bhuvangu commented on Sep 7, 2025

bhuvangu commented on Sep 9, 2025

debora-ito commented on Aug 7, 2026

brigidmulligan commented on Aug 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions