[DinonowDev]

Summary

• Map HTTP 499 to client_disconnected in ERROR_TYPES / default messages so disconnects are not logged as invalid_request_error with an empty code.
• Let buildErrorBody() keep an optional caller-supplied type/code instead of always re-deriving from the status table.
• Pass stream-failure classification through from createStreamFailureFinalizers so abort handling reaches the request log correctly.

Fixes #8535

Test plan

• node --import tsx/esm --test tests/unit/error-config.test.ts tests/unit/stream-failure-499-classification.test.ts tests/unit/error-message-sanitization.test.ts (42/42 pass)
• CI unit / lint on the PR

Made with Cursor

[diegosouzapw]

Thanks for the fix — this closes a real gap: getErrorInfo(499) had no entry in ERROR_TYPES, so it fell through to {type: "invalid_request_error", code: ""} even though the internal errorCode on the same failure event was already client_disconnected. Your change makes the JSON body match the log.

I re-ran the included tests plus the neighboring 499/combo/chatCore suites on the PR head and everything passes (114 tests total), and typecheck:core is clean. I also checked that nothing in the codebase keys off the old 499 shape (invalid_request_error + empty code), so this doesn't look like it breaks any existing consumer.

One tiny, non-blocking nit for a future pass: docs/security/ERROR_SANITIZATION.md documents buildErrorBody's optional 3rd argument (upstreamDetails) but not the new optional 4th argument (classification) — worth a one-line addition whenever convenient, doesn't need to hold up this PR.

[DinonowDev]

Thanks for the fix — this closes a real gap: getErrorInfo(499) had no entry in ERROR_TYPES, so it fell through to {type: "invalid_request_error", code: ""} even though the internal errorCode on the same failure event was already client_disconnected. Your change makes the JSON body match the log.

I re-ran the included tests plus the neighboring 499/combo/chatCore suites on the PR head and everything passes (114 tests total), and typecheck:core is clean. I also checked that nothing in the codebase keys off the old 499 shape (invalid_request_error + empty code), so this doesn't look like it breaks any existing consumer.

One tiny, non-blocking nit for a future pass: docs/security/ERROR_SANITIZATION.md documents buildErrorBody's optional 3rd argument (upstreamDetails) but not the new optional 4th argument (classification) — worth a one-line addition whenever convenient, doesn't need to hold up this PR.

Thanks for the thorough review — really appreciate you checking the tests, typecheck, and that nothing keyed off the old 499 shape.

Addressed the docs nit in 0061d42: docs/security/ERROR_SANITIZATION.md now documents the optional 4th classification argument on buildErrorBody (caller-supplied type/code wins over the status-derived defaults, e.g. HTTP 499 → client_disconnected).