Repository navigation
chore: make enabled property work consistently in withLargeResponse runner - #10
Merged
Merged
Conversation
- Updated README to clarify the behavior of the `enabled` option for the runner, emphasizing its per-request resolution. - Improved test descriptions for clarity and accuracy regarding the handling of globally disabled requests and per-request options. - Added tests to ensure that per-request options are stripped correctly when the request remains disabled.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
withLargeResponse now resolves enabled per request on the runner path, so the same global-off / per-call-on combination the interceptor supports finally works on a runner too (same behaviour of axios http interceptor)
👉 Background
The runner read enabled once at wrap time and returned the original runner untouched when it was false — so a global enabled: false could never be re-enabled per request, an asymmetry with the interceptor that was documented as a deliberate quirk rather than fixed.
👉 What's Fixed?
Wrap-time enabled early-return dropped from large-response-runner.ts — the wrapper is always installed and decides per call
A per-request enabled: true now re-enables a globally disabled runner, matching the interceptor path
The [NAMESPACE] request key is stripped even when the request stays disabled, so it never reaches the transport as payload