fix(runtime): Preserve errorType etc through IResponseException roundtrip#27533
fix(runtime): Preserve errorType etc through IResponseException roundtrip#27533markfields wants to merge 6 commits into
Conversation
Stamps IResponseException props on, but there's a latent risk of collision with Error or telemetry props. Will address that next
… bag. This gives us a good offramp from the overloaded string-keyed props on the Error object itself. Once external usages migrate to the new thing (which we'll export as legacy-beta) we can remove the string props.
…es to IErrorWithResponseExceptionMetadata
…nal usages to IErrorWithResponseExceptionMetadata" This reverts commit cf3c821.
|
Hi! Thank you for opening this PR. Want me to review it? Based on the diff (167 lines, 3 files), I've queued these reviewers:
How this works
|
|
Leaving as a draft because I anticipate this could have unintended side effects in 1P partner repo we tightly integrate with, due to strongly-typed errors newly propagating where they should have been the whole time. So I'm going to wait until after the 2.110 release to merge this. |
1 participant
Fixes AB#75494
Description
If we are under a "request"-based API like FluidDataStoreRuntime.request, when we throw a DataProcessingError with tons of telemetry props plus all LoggingError's goodness, all that gets stripped off as it temporarily is converted to an IResponseException (which only has message and stack and a few response-related props) and back to Error.
Instead we should stash the original error on there and use it (with the extra response-related props) when going back to Error shape.
This is obscuring important errors that propagate up to host error logging.
Breaking Changes
None, this preserves the behavior needed by consumers of the implicit
IResponseExceptioncontract (despite it being not exported)