Fail to understand how I should handle connection failures from a client.

[akc42]

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.

[jasnell]

Looks like this is an area we need to tighten up a bit. I'll look into it.

[akc42]

I have solved the problem by listening on socketError on the session, which I got from the code, and then realised that is what the docs said..

[jasnell]

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 associated ClientHttp2Session. If no 'socketError' event is registered, the 'error' event is re-emitted on the Socket via a call to socket.destroy(error).

On the server side, it's the same except that a default listener for the 'socketError' event on the ServerHttp2Session is registered that forwards the 'socketError' on to the owning Http2Server instance if no other 'socketError' events are registered. This essentially means that the Socket '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 Http2Session or 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.