-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ERR_INTERNAL_ASSERTION] with http keepAlive #59
Comments
I don't have Node.js v12.4 at hand yet to test, but on Travis all except a UCS-2 encoding tests pass (on v12.0.0 everything passes). Would you mind pasting at least some snippets of how Mitm.js is used in your tests? I'll try to skim if something changed since Node v12.0 that could break Mitm.js. |
Thanks for the reply! I made a reduced repo, unfortunately it doesn't trigger the error, but it will at least demonstrate the context: I'll update this issue if I'm able to reproduce it independent of my project. It seems to be something specific to the Stripe SDK; if I use the request module to manually POST to api.stripe.com, the issue doesn't occur. |
I briefly skimmed https://github.com/stripe/stripe-node/blob/e542902dd8fbe591fe3c3ce07a7e89d1d60e4cf7/lib/StripeResource.js#L320 and nothing particularly jumped out, so I'll await for your update when you manage to isolate it a little. |
Update: I was able to reproduce it! It just needed more iterations. Curiously, it fails on the 63rd test (could be a coincidence, but this is 2^6-1, which makes me wonder if there's a buffer somewhere that gets full). The issue occurs on Node v10.16.0, and also v12.6.0. |
Another interesting observation: the number of test runs needed to induce a failure changes based on the size of the HTTP body. If you make the mock body larger, mitm will fail sooner, and vice-versa. One more clue I found: By running git-bisect on the Stripe packages, I was able to locate start of the problem: stripe/stripe-node@e67dd8ce4e It appears to be related to keepAlive. If I hack the Stripe code to |
aha! I finally got a "clean" reproduction with no other dependencies. It's definitely keepalive: |
Thanks for the research! I bet it's to do with the fact that Mitm.js kind-of forces a fresh connection every time ( Lines 59 to 63 in 58e0673
|
I can confirm it goes haywire when you pass an var data = _.times(128, function() { return "deadbeef" }).join("")
data.length.must.equal(1024)
var count = 0
this.mitm.on("request", function(_req, res) {
;++count
res.end(data)
})
var agent = new Http.Agent({keepAlive: true})
var res = _.times(128, noop).reduce(function(res) {
return res.then(function() {
return new Promise(function(resolve) {
var client = Http.request({host: "foo", agent: agent})
client.end()
client.on("response", function(res) {
res.on("data", noop)
res.on("end", resolve)
})
})
})
}, Promise.resolve())
res.then(function() {
count.must.equal(128)
done()
}, done) I'll see what I can do. Hopefully I can make Mitm.js work with re-used sockets, but for a quick fix until then I suggest disabling |
I have a similar issue for the same cause. I use mitm with ava. Ava allow me to use some context inherent of unit test. test.beforeEach(t => {
const mitm = Mitm();
mitm.on("request", function(request, response) {
switch(t.context.something) {
case "behavior A":
response.end("something");
break;
case "behavior B":
response.end("something else");
break;
}
});
t.context.mitm = mitm;
});
test.afterEach.always("cleanup", t => {
t.context.mitm.disable();
});
test.serial("test A", async t => {
t.context.something = "behavior A";
// calling http request ...
});
test.serial("test B", async t => {
t.context.something = "behavior B";
// calling http request ...
}); When i use keep alive feature, disable mitm has no effect (serial execution of tests). First test is ok but second test fail cause both request handlers (both instance even the disabled one) are called. handler with This cause second test to get result of first request. |
I guess this might be related to this keep-alive problem I ran into a few years ago: #36 I'll just close that one and hope you get to the bottom of it here :) |
Ah, indeed, @papandreou. Thanks for that! I re-opened it to remember to take a look once I jump into this. :) |
Hey - I stumbled upon the same weird issue with keepAlive. |
Mitm has problems when agents like axios want to keep the connection alive. this probably to a buffer overflow. This is why we destroy the request up on finish sending data (moll/node-mitm#59 (comment))
Repro: https://github.com/dylantack/mitm_err_internal_assertion
( moved from Error [ERR_INTERNAL_ASSERTION] nodejs/node#28274 )
When running some Jest tests, I got this:
This is the entire stack trace. The line generating the error is here:
https://github.com/moll/node-mitm/blob/v1.7.0/lib/internal_socket.js#L156
There are also some warnings:
thanks!
The text was updated successfully, but these errors were encountered: