-
Notifications
You must be signed in to change notification settings - Fork 8.1k
-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
[Core] aborted$ stream defined in core/server/http/router/request.ts doesn't work in some cases #125240
Comments
Pinging @elastic/kibana-core (Team:Core) |
AnalysisI initially though this was related to the basePath proxy, but the behavior is the exact same when running with Then, I used #125069 to try to understand the differences between the working and non-working scenarios. My conclusion is that it's failing for requests having a payload:
Then, I wanted to see if the problem was in our internal observers, or deeper, so I adapted I then adapted this test:
To use a POST request with payload instead of the current GET, and I confirmed that the test went red (because the observable does not emit). Interesting though, in some case only: the payload needs to be validated/parsed for the test to fail. With this request: const incomingRequest = supertest(innerServer.listener)
.post('/')
.send({ hello: 'dolly' }) this fails: router.post(
{ path: '/', validate: { body: schema.any() } }, but this passes: router.post(
{ path: '/', validate: false }, So it likely has something to do with the low level request's payload accessing, parsing, or associated route configuration. I checked where we were using the value of kibana/src/core/server/http/router/router.ts Lines 187 to 197 in 3c8fa52
So I played with the
So, somehow, HAPI's Not sure how to progress further. We should probably try to create a reproduction scenario with a plain HAPI server to confirm our observations. Side note - the
|
I isolated the problem in a test case that is using import { Server } from '@hapi/hapi';
import supertest from 'supertest';
const delay = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));
const deferred = <T = unknown>(): {
promise: Promise<T>;
resolve: (value: T) => void;
reject: (error: any) => void;
} => {
let resolve: (value: T) => void;
let reject: (error: any) => void;
const promise = new Promise<T>((_resolve, _reject) => {
resolve = _resolve;
reject = _reject;
});
return {
promise,
resolve: resolve!,
reject: reject!,
};
};
describe('aborted event bug', () => {
let server: Server;
let request: supertest.SuperTest<supertest.Test>;
beforeEach(() => {
server = new Server({
host: '127.0.0.1',
port: 6666,
});
request = supertest('http://127.0.0.1:6666');
});
afterEach(async () => {
await server.stop();
});
const runTest = async (options: { output: 'stream' | 'data' }) => {
let abortedReceived = false;
const { promise: responseClosedPromise, resolve: responseClosedResolve } = deferred<void>();
server.route({
method: 'POST',
path: '/test',
options: {
payload: {
output: options.output,
},
},
handler: async (req, h) => {
req.raw.req.on('aborted', () => { // same with req.events.on('disconnect'
abortedReceived = true;
});
req.raw.res.on('close', () => {
responseClosedResolve();
});
await delay(3000);
return h.response('foo');
},
});
await server.start();
const incomingRequest = request.post('/test').send({ hello: 'dolly' }).end();
setTimeout(() => incomingRequest.abort(), 100);
await responseClosedPromise;
expect(abortedReceived).toEqual(true);
};
// pass
it('should work with `options.payload.output=stream`', async () => {
await runTest({ output: 'stream' });
});
// fail
it('should work with `options.payload.output=data`', async () => {
await runTest({ output: 'data' });
});
}); at this point I think the next step is to open an issue upstream |
Opened hapijs/hapi#4339 |
More context from hapijs/hapi#4315
Also it seems that node is considering that as working as intended, as nodejs/node#40775 was closed. |
Currently working on a workaround based on a suggestion found in nodejs/node#40775. It seems to be passing the tests, I should open a PR shortly. cc @flash1293 @alexwizp |
This is a follow-up PR issue for #125069 because we didn't find the answer.
The text was updated successfully, but these errors were encountered: