Summary
The fetch interceptor currently calls matcher and onIntercept directly in the request path. If either callback throws, the original fetch() call rejects even when the network request itself succeeded.
That makes interception logic capable of breaking application behavior.
Current behavior
A successful response can be converted into a rejected fetch() promise when user-supplied interception code throws.
Expected behavior
Interception should be observational by default. Callback failures should not change the success or failure of the original fetch() unless the library explicitly documents that behavior.
Impact
- Logging or analytics code can break production requests
- Consumers have to wrap every callback defensively to avoid changing network semantics
- The library is not transparently safe to enable around existing code
Suggested acceptance criteria
- Exceptions thrown by
matcher or onIntercept do not reject a successful fetch() call
- Failure handling behavior is documented
- Tests cover callback exceptions for both matcher and interception callbacks
Summary
The fetch interceptor currently calls
matcherandonInterceptdirectly in the request path. If either callback throws, the originalfetch()call rejects even when the network request itself succeeded.That makes interception logic capable of breaking application behavior.
Current behavior
A successful response can be converted into a rejected
fetch()promise when user-supplied interception code throws.Expected behavior
Interception should be observational by default. Callback failures should not change the success or failure of the original
fetch()unless the library explicitly documents that behavior.Impact
Suggested acceptance criteria
matcheroronInterceptdo not reject a successfulfetch()call