fix(anthropic): enable messages.stream() in auto-instrumentation e2e tests by Qard · Pull Request #1696 · braintrustdata/braintrust-sdk-javascript

Stephen Belanger (Qard) · 2026-03-27T15:29:24Z

Summary

The root cause of this issue was fixed by PR #1617, which patched TracingChannel.prototype.tracePromise to preserve the original APIPromise object rather than wrapping it in a plain .then() chain that strips .withResponse().

This PR removes the e2e workaround that was preventing client.messages.stream() from being tested in the auto-hook instrumentation path.

What was the workaround?

runAutoAnthropicInstrumentation was forcing useMessagesStreamHelper: false, which caused the "anthropic-stream-with-response-operation" scenario to use client.messages.create({ stream: true }) instead of client.messages.stream(). This avoided the failure but left the real code path untested.

Why is the fix correct?

client.messages.stream() internally calls this.create({...}).withResponse(). The instrumented create returns the original APIPromise (not a wrapped plain Promise), so .withResponse() is still available. The APIPromise constructor check (result.constructor !== Promise) correctly routes to the preserve-original branch in the patched tracePromise.

All 140 anthropic e2e tests pass with both wrapper and auto-hook instrumentation paths using messages.stream().

Test plan

All 140 anthropic e2e tests pass with messages.stream() enabled (pnpm vitest run scenarios/anthropic-instrumentation/scenario.test.ts)
CI e2e and js-test checks pass

🤖 Generated with Claude Code

…tests (#1592) The root cause of #1592 was fixed by PR #1617: `patch-tracing-channel.ts` now preserves the original `APIPromise` object (with `.withResponse()`) instead of wrapping it in a plain `.then()` chain when the result is a Promise subclass. Remove the `useMessagesStreamHelper: false` workaround that was causing the auto-hook instrumentation path to avoid `client.messages.stream()`. The 140 anthropic e2e tests all pass with `messages.stream()` enabled in both the wrapper and auto-hook paths. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Now that auto-hook instrumentation also uses client.messages.stream(), the useMessagesStreamHelper flag is always true and the fallback branch is unreachable. Remove the parameter and simplify the stream-with-response operation to unconditionally use client.messages.stream(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…tion

Stephen Belanger (Qard) · 2026-03-27T15:29:24Z

Summary

Closes#1592.

The root cause of this issue was fixed by PR #1617, which patched TracingChannel.prototype.tracePromise to preserve the original APIPromise object rather than wrapping it in a plain .then() chain that strips .withResponse().

This PR removes the e2e workaround that was preventing client.messages.stream() from being tested in the auto-hook instrumentation path.

What was the workaround?

runAutoAnthropicInstrumentation was forcing useMessagesStreamHelper: false, which caused the "anthropic-stream-with-response-operation" scenario to use client.messages.create({ stream: true }) instead of client.messages.stream(). This avoided the failure but left the real code path untested.

Why is the fix correct?

client.messages.stream() internally calls this.create({...}).withResponse(). The instrumented create returns the original APIPromise (not a wrapped plain Promise), so .withResponse() is still available. The APIPromise constructor check (result.constructor !== Promise) correctly routes to the preserve-original branch in the patched tracePromise.

All 140 anthropic e2e tests pass with both wrapper and auto-hook instrumentation paths using messages.stream().

Test plan

All 140 anthropic e2e tests pass with messages.stream() enabled (pnpm vitest run scenarios/anthropic-instrumentation/scenario.test.ts)
CI e2e and js-test checks pass

🤖 Generated with Claude Code

…tests (#1592) The root cause of #1592 was fixed by PR #1617: `patch-tracing-channel.ts` now preserves the original `APIPromise` object (with `.withResponse()`) instead of wrapping it in a plain `.then()` chain when the result is a Promise subclass. Remove the `useMessagesStreamHelper: false` workaround that was causing the auto-hook instrumentation path to avoid `client.messages.stream()`. The 140 anthropic e2e tests all pass with `messages.stream()` enabled in both the wrapper and auto-hook paths. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Now that auto-hook instrumentation also uses client.messages.stream(), the useMessagesStreamHelper flag is always true and the fallback branch is unreachable. Remove the parameter and simplify the stream-with-response operation to unconditionally use client.messages.stream(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…tion

Stephen Belanger (Qard) · 2026-03-27T15:29:24Z

Summary

Closes#1592.

The root cause of this issue was fixed by PR #1617, which patched TracingChannel.prototype.tracePromise to preserve the original APIPromise object rather than wrapping it in a plain .then() chain that strips .withResponse().

This PR removes the e2e workaround that was preventing client.messages.stream() from being tested in the auto-hook instrumentation path.

What was the workaround?

runAutoAnthropicInstrumentation was forcing useMessagesStreamHelper: false, which caused the "anthropic-stream-with-response-operation" scenario to use client.messages.create({ stream: true }) instead of client.messages.stream(). This avoided the failure but left the real code path untested.

Why is the fix correct?

client.messages.stream() internally calls this.create({...}).withResponse(). The instrumented create returns the original APIPromise (not a wrapped plain Promise), so .withResponse() is still available. The APIPromise constructor check (result.constructor !== Promise) correctly routes to the preserve-original branch in the patched tracePromise.

All 140 anthropic e2e tests pass with both wrapper and auto-hook instrumentation paths using messages.stream().

Test plan

All 140 anthropic e2e tests pass with messages.stream() enabled (pnpm vitest run scenarios/anthropic-instrumentation/scenario.test.ts)
CI e2e and js-test checks pass

🤖 Generated with Claude Code

…tests (#1592) The root cause of #1592 was fixed by PR #1617: `patch-tracing-channel.ts` now preserves the original `APIPromise` object (with `.withResponse()`) instead of wrapping it in a plain `.then()` chain when the result is a Promise subclass. Remove the `useMessagesStreamHelper: false` workaround that was causing the auto-hook instrumentation path to avoid `client.messages.stream()`. The 140 anthropic e2e tests all pass with `messages.stream()` enabled in both the wrapper and auto-hook paths. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Now that auto-hook instrumentation also uses client.messages.stream(), the useMessagesStreamHelper flag is always true and the fallback branch is unreachable. Remove the parameter and simplify the stream-with-response operation to unconditionally use client.messages.stream(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…tion

Stephen Belanger (Qard) · 2026-03-27T15:29:24Z

Summary

Closes#1592.

The root cause of this issue was fixed by PR #1617, which patched TracingChannel.prototype.tracePromise to preserve the original APIPromise object rather than wrapping it in a plain .then() chain that strips .withResponse().

This PR removes the e2e workaround that was preventing client.messages.stream() from being tested in the auto-hook instrumentation path.

What was the workaround?

runAutoAnthropicInstrumentation was forcing useMessagesStreamHelper: false, which caused the "anthropic-stream-with-response-operation" scenario to use client.messages.create({ stream: true }) instead of client.messages.stream(). This avoided the failure but left the real code path untested.

Why is the fix correct?

client.messages.stream() internally calls this.create({...}).withResponse(). The instrumented create returns the original APIPromise (not a wrapped plain Promise), so .withResponse() is still available. The APIPromise constructor check (result.constructor !== Promise) correctly routes to the preserve-original branch in the patched tracePromise.

All 140 anthropic e2e tests pass with both wrapper and auto-hook instrumentation paths using messages.stream().

Test plan

All 140 anthropic e2e tests pass with messages.stream() enabled (pnpm vitest run scenarios/anthropic-instrumentation/scenario.test.ts)
CI e2e and js-test checks pass

🤖 Generated with Claude Code

…tests (#1592) The root cause of #1592 was fixed by PR #1617: `patch-tracing-channel.ts` now preserves the original `APIPromise` object (with `.withResponse()`) instead of wrapping it in a plain `.then()` chain when the result is a Promise subclass. Remove the `useMessagesStreamHelper: false` workaround that was causing the auto-hook instrumentation path to avoid `client.messages.stream()`. The 140 anthropic e2e tests all pass with `messages.stream()` enabled in both the wrapper and auto-hook paths. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Now that auto-hook instrumentation also uses client.messages.stream(), the useMessagesStreamHelper flag is always true and the fallback branch is unreachable. Remove the parameter and simplify the stream-with-response operation to unconditionally use client.messages.stream(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…tion

Stephen Belanger (Qard) · 2026-03-27T15:29:24Z

Summary

Closes#1592.

The root cause of this issue was fixed by PR #1617, which patched TracingChannel.prototype.tracePromise to preserve the original APIPromise object rather than wrapping it in a plain .then() chain that strips .withResponse().

This PR removes the e2e workaround that was preventing client.messages.stream() from being tested in the auto-hook instrumentation path.

What was the workaround?

runAutoAnthropicInstrumentation was forcing useMessagesStreamHelper: false, which caused the "anthropic-stream-with-response-operation" scenario to use client.messages.create({ stream: true }) instead of client.messages.stream(). This avoided the failure but left the real code path untested.

Why is the fix correct?

client.messages.stream() internally calls this.create({...}).withResponse(). The instrumented create returns the original APIPromise (not a wrapped plain Promise), so .withResponse() is still available. The APIPromise constructor check (result.constructor !== Promise) correctly routes to the preserve-original branch in the patched tracePromise.

All 140 anthropic e2e tests pass with both wrapper and auto-hook instrumentation paths using messages.stream().

Test plan

All 140 anthropic e2e tests pass with messages.stream() enabled (pnpm vitest run scenarios/anthropic-instrumentation/scenario.test.ts)
CI e2e and js-test checks pass

🤖 Generated with Claude Code

…tests (#1592) The root cause of #1592 was fixed by PR #1617: `patch-tracing-channel.ts` now preserves the original `APIPromise` object (with `.withResponse()`) instead of wrapping it in a plain `.then()` chain when the result is a Promise subclass. Remove the `useMessagesStreamHelper: false` workaround that was causing the auto-hook instrumentation path to avoid `client.messages.stream()`. The 140 anthropic e2e tests all pass with `messages.stream()` enabled in both the wrapper and auto-hook paths. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Now that auto-hook instrumentation also uses client.messages.stream(), the useMessagesStreamHelper flag is always true and the fallback branch is unreachable. Remove the parameter and simplify the stream-with-response operation to unconditionally use client.messages.stream(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…tion

Stephen Belanger (Qard) · 2026-03-27T15:29:24Z

Summary

Closes#1592.

The root cause of this issue was fixed by PR #1617, which patched TracingChannel.prototype.tracePromise to preserve the original APIPromise object rather than wrapping it in a plain .then() chain that strips .withResponse().

This PR removes the e2e workaround that was preventing client.messages.stream() from being tested in the auto-hook instrumentation path.

What was the workaround?

runAutoAnthropicInstrumentation was forcing useMessagesStreamHelper: false, which caused the "anthropic-stream-with-response-operation" scenario to use client.messages.create({ stream: true }) instead of client.messages.stream(). This avoided the failure but left the real code path untested.

Why is the fix correct?

client.messages.stream() internally calls this.create({...}).withResponse(). The instrumented create returns the original APIPromise (not a wrapped plain Promise), so .withResponse() is still available. The APIPromise constructor check (result.constructor !== Promise) correctly routes to the preserve-original branch in the patched tracePromise.

All 140 anthropic e2e tests pass with both wrapper and auto-hook instrumentation paths using messages.stream().

Test plan

All 140 anthropic e2e tests pass with messages.stream() enabled (pnpm vitest run scenarios/anthropic-instrumentation/scenario.test.ts)
CI e2e and js-test checks pass

🤖 Generated with Claude Code

…tests (#1592) The root cause of #1592 was fixed by PR #1617: `patch-tracing-channel.ts` now preserves the original `APIPromise` object (with `.withResponse()`) instead of wrapping it in a plain `.then()` chain when the result is a Promise subclass. Remove the `useMessagesStreamHelper: false` workaround that was causing the auto-hook instrumentation path to avoid `client.messages.stream()`. The 140 anthropic e2e tests all pass with `messages.stream()` enabled in both the wrapper and auto-hook paths. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Now that auto-hook instrumentation also uses client.messages.stream(), the useMessagesStreamHelper flag is always true and the fallback branch is unreachable. Remove the parameter and simplify the stream-with-response operation to unconditionally use client.messages.stream(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…tion

Stephen Belanger (Qard) · 2026-03-27T15:29:24Z

Summary

Closes#1592.

The root cause of this issue was fixed by PR #1617, which patched TracingChannel.prototype.tracePromise to preserve the original APIPromise object rather than wrapping it in a plain .then() chain that strips .withResponse().

This PR removes the e2e workaround that was preventing client.messages.stream() from being tested in the auto-hook instrumentation path.

What was the workaround?

runAutoAnthropicInstrumentation was forcing useMessagesStreamHelper: false, which caused the "anthropic-stream-with-response-operation" scenario to use client.messages.create({ stream: true }) instead of client.messages.stream(). This avoided the failure but left the real code path untested.

Why is the fix correct?

client.messages.stream() internally calls this.create({...}).withResponse(). The instrumented create returns the original APIPromise (not a wrapped plain Promise), so .withResponse() is still available. The APIPromise constructor check (result.constructor !== Promise) correctly routes to the preserve-original branch in the patched tracePromise.

All 140 anthropic e2e tests pass with both wrapper and auto-hook instrumentation paths using messages.stream().

Test plan

All 140 anthropic e2e tests pass with messages.stream() enabled (pnpm vitest run scenarios/anthropic-instrumentation/scenario.test.ts)
CI e2e and js-test checks pass

🤖 Generated with Claude Code

…tests (#1592) The root cause of #1592 was fixed by PR #1617: `patch-tracing-channel.ts` now preserves the original `APIPromise` object (with `.withResponse()`) instead of wrapping it in a plain `.then()` chain when the result is a Promise subclass. Remove the `useMessagesStreamHelper: false` workaround that was causing the auto-hook instrumentation path to avoid `client.messages.stream()`. The 140 anthropic e2e tests all pass with `messages.stream()` enabled in both the wrapper and auto-hook paths. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Now that auto-hook instrumentation also uses client.messages.stream(), the useMessagesStreamHelper flag is always true and the fallback branch is unreachable. Remove the parameter and simplify the stream-with-response operation to unconditionally use client.messages.stream(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…tion

Stephen Belanger (Qard) · 2026-03-27T15:29:24Z

Summary

Closes#1592.

The root cause of this issue was fixed by PR #1617, which patched TracingChannel.prototype.tracePromise to preserve the original APIPromise object rather than wrapping it in a plain .then() chain that strips .withResponse().

This PR removes the e2e workaround that was preventing client.messages.stream() from being tested in the auto-hook instrumentation path.

What was the workaround?

runAutoAnthropicInstrumentation was forcing useMessagesStreamHelper: false, which caused the "anthropic-stream-with-response-operation" scenario to use client.messages.create({ stream: true }) instead of client.messages.stream(). This avoided the failure but left the real code path untested.

Why is the fix correct?

client.messages.stream() internally calls this.create({...}).withResponse(). The instrumented create returns the original APIPromise (not a wrapped plain Promise), so .withResponse() is still available. The APIPromise constructor check (result.constructor !== Promise) correctly routes to the preserve-original branch in the patched tracePromise.

All 140 anthropic e2e tests pass with both wrapper and auto-hook instrumentation paths using messages.stream().

Test plan

All 140 anthropic e2e tests pass with messages.stream() enabled (pnpm vitest run scenarios/anthropic-instrumentation/scenario.test.ts)
CI e2e and js-test checks pass

🤖 Generated with Claude Code

…tests (#1592) The root cause of #1592 was fixed by PR #1617: `patch-tracing-channel.ts` now preserves the original `APIPromise` object (with `.withResponse()`) instead of wrapping it in a plain `.then()` chain when the result is a Promise subclass. Remove the `useMessagesStreamHelper: false` workaround that was causing the auto-hook instrumentation path to avoid `client.messages.stream()`. The 140 anthropic e2e tests all pass with `messages.stream()` enabled in both the wrapper and auto-hook paths. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Now that auto-hook instrumentation also uses client.messages.stream(), the useMessagesStreamHelper flag is always true and the fallback branch is unreachable. Remove the parameter and simplify the stream-with-response operation to unconditionally use client.messages.stream(). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…tion

Stephen Belanger (Qard) requested review from Abhijeet Prasad (AbhiPrasad) and Luca Forstner (lforst)March 27, 2026 16:11

Stephen Belanger (Qard) self-assigned this Mar 27, 2026

Stephen Belanger (Qard) added the bug label Mar 27, 2026

Luca Forstner (lforst) approved these changes Mar 27, 2026
View reviewed changes

Comment threade2e/scenarios/anthropic-instrumentation/scenario.impl.mjs

Stephen Belanger (Qard)force-pushed the fix/anthropic-stream-helper-auto-instrumentation branch from aeca65d to cb891c0Compare March 31, 2026 08:35

Stephen Belanger (Qard)and others added 2 commits April 1, 2026 01:17

Stephen Belanger (Qard)force-pushed the fix/anthropic-stream-helper-auto-instrumentation branch from cb891c0 to 959ef0eCompare March 31, 2026 17:18

Merge branch 'main' into fix/anthropic-stream-helper-auto-instrumenta…
ff1fb64
…tion

Stephen Belanger (Qard) merged commit 07efe92 into mainApr 1, 2026
47 checks passed

Stephen Belanger (Qard) deleted the fix/anthropic-stream-helper-auto-instrumentation branch April 1, 2026 14:05