feat: dump interceptor #3118
feat: dump interceptor #3118
Conversation
lib/interceptor/dump.js
Outdated
| return true | ||
| } | ||
|
|
||
| // TODO: shall we forward the rest of the data to the handler or better to abort? |
There was a problem hiding this comment.
Suggestions? I might be had it wrong here 🤔
There was a problem hiding this comment.
you must keep the data flowing from the request or error/abort it. The latter will destroy the connection. It should be a user choice, but I would error/abort the socket by default.
Co-authored-by: Robert Nagy <ronagy@icloud.com>
Do you mean to not directly abort the connection, but rather let it flow? Or how so? |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3118 +/- ##
==========================================
- Coverage 94.17% 94.15% -0.03%
==========================================
Files 90 91 +1
Lines 24559 24692 +133
==========================================
+ Hits 23128 23248 +120
- Misses 1431 1444 +13 ☔ View full report in Codecov by Sentry. |
lib/interceptor/dump.js
Outdated
| return true | ||
| } | ||
|
|
||
| // TODO: shall we forward the rest of the data to the handler or better to abort? |
There was a problem hiding this comment.
you must keep the data flowing from the request or error/abort it. The latter will destroy the connection. It should be a user choice, but I would error/abort the socket by default.
|
@ronag ptal |
Co-authored-by: Robert Nagy <ronagy@icloud.com>
Co-authored-by: Robert Nagy <ronagy@icloud.com>
|
@ronag can you take a look; I'll fix the remaining test later today |
lib/interceptor/dump.js
Outdated
| this.#abort(this.#reason) | ||
| return false | ||
| } | ||
| this.#handler.onData('') |
There was a problem hiding this comment.
Otherwise the request keeps hanging, tried a workaround without luck; find it quite counterintuitive but most likely is something that might need to be addressed at the request level, but not sure the scope of this PR
There was a problem hiding this comment.
I'd like to address this before landing. Do you have minimal a repro? I can take a look.
There was a problem hiding this comment.
nvm, I found the issue; it was on me, the request was in the aborted state and couldn't continue because already aborted but I never called the onError hook from the original handler. That made the work
There was a problem hiding this comment.
Just to be clear for me here are two cases:
- You want to dump the response regardless
- You want to dump the response, if aborting and avoid closing the connection
I guess the follow configuration apply at the moment:
- { maxSize: 16 * 1024, dumpOnAbort: true }
- { max Size: 9999999999, dumpOnAbort: true }
These are inclusive.
This usually means you want to keep the connection alive, just dump the response's body, with the current setup is possible, even with the defaults.
This is also already covered, with the defaults.
The default does that
This is not currently covered as regardless of the combination, you'll still be dumping the response even if not aborted; do we want to cover this case?
Already covered by disabling Anything else that I might be missing? |
|
It seems only fails on windows but cannot understand fully why 🤔 |
This relates to...
Rationale
Relates to #2835
Changes
Features
Bug Fixes
Breaking Changes and Deprecations
Status