Repository navigation
Fail to understand how I should handle connection failures from a client. #184
Description
I am trying to construct a client that will handle failure conditions correctly. I am currently testing a situation where the client tries to connect to a server that is not running. I can see at the socket level a tls.connect is failing with "Connection Refused", but this doesn't seem to be translating into anything I can use.
Here is a promise I am trying to create for the session
this.sessionPromise = new Promise((resolve,reject) => {
function onSessionError(err) {
session.removeListener('error', onSessionError);
reject(err);
}
const session = http2.connect(
`https://localhost:${process.env.PAS_HTTPS_PORT}`,
{ rejectUnauthorized: false},
() => {
session.removeListener('error', onSessionError);
resolve(session);
}
);
session.on('error', onSessionError);
});but that promise never resolves.
In a previous attempt, I didn't wait for the connection to establish, and after creating the connection immediately created a request - something like this
const session = http2.connect(
`https://localhost:${process.env.PAS_HTTPS_PORT}`,
{ rejectUnauthorized: false}
);
const req = session.request(headers)
req.on('error', /*did something here */)
req.on('end', /* did something here */)In that scenario, the 'end' event was raised pretty quickly - but no error.event. Unfortunately that makes it very difficult to understand why the 'end' event was raised, so I didn't pursue it.
What is the correct way of dealing with this? docs don't give much clue.
Activity
jasnell commentedon Jul 17, 2017
Looks like this is an area we need to tighten up a bit. I'll look into it.
akc42 commentedon Jul 18, 2017
I have solved the problem by listening on
socketErroron the session, which I got from the code, and then realised that is what the docs said..jasnell commentedon Jul 19, 2017
Good, ok. I'm going to add a commit to the initial PR that attempts to refine this just a bit. It should not impact the actual flow here so you shouldn't need to change anything.
Essentially the flow is this:
On the client side, when the Socket emits an
'error'event, that is forwarded to the'socketError'event on the associatedClientHttp2Session. If no'socketError'event is registered, the'error'event is re-emitted on the Socket via a call tosocket.destroy(error).On the server side, it's the same except that a default listener for the
'socketError'event on theServerHttp2Sessionis registered that forwards the'socketError'on to the owningHttp2Serverinstance if no other'socketError'events are registered. This essentially means that theSocket'error'event will not be re-emitted on the server side.The big caveat, however, is that application should should never write directly to the Socket associated with an
Http2Sessionor the HTTP/2 session state will get out of sync and will be useless. The only viable option with a'socketError'event is to tear everything down.http2: refinement and test for socketError
http2: refinement and test for socketError
http2: refinement and test for socketError
http2: refinement and test for socketError
http2: refinement and test for socketError
http2: refinement and test for socketError