fix(responses): reject with OpenAIError when the stream emits an error event - #2021

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c34bfea5d9

The conversion is still incomplete in two valid consumption paths:

1. #addEvent calls accumulateResponse() before checking event.type, so an error frame sent before response.created never reaches the new branch. It still rejects with the accumulator's generic OpenAIError and loses the server message/code/param. Please convert error frames before snapshot accumulation and add coverage for an initial error frame.

2. The raw error frame is emitted through the generic event channel before the APIError is thrown, while ResponseStream[Symbol.asyncIterator] only rejects reads that are pending at the instant the error fires and does not retain the failure. A normal for await consumer therefore observes [response.created, error] and then completes cleanly; only a separate finalResponse() call sees the APIError. Please make async iteration reject consistently (the failure-retention pattern in EventStream.events() is a useful model) and add a regression test.

Validation at c34bfea5d94941e37038bb6ac8834240f84590c4: the focused ResponseStream suite passed (6/6), Prettier and ESLint passed on changed files, TypeScript checking passed, the package build passed, and git diff --check passed. I also reproduced both cases against the built package.

Validated against the actual first-party/Azure nested SSE error contract and the documented flat compatibility shape. Errors are normalized before accumulation, API metadata and request IDs are preserved, and async iteration reuses EventStream.events to retain delayed failures. Verified 1,701 unit tests, focused live-SSE/replay/cancellation cases, lint, TypeScript 4.9/6 published checks, and full CJS/ESM build.