LSP server triggers unhandled rejection when schema endpoint is unavailable

[rchl]

With a config file like:

module.exports = {
    schema: 'http://localhost:5000/browse/api'
}

And the graphql server not actually running, the LSP server will try to connect to the endpoint and trigger promise rejection that is not unhandled:

internal/process/warning.js:40 (node:8940) UnhandledPromiseRejectionWarning: FetchError: request to http://localhost:5000/browse/api failed, reason: connect ECONNREFUSED 127.0.0.1:5000
    at ClientRequest.<anonymous> (/Users/me/github/graphiql/node_modules/node-fetch/lib/index.js:1455:11)
    at ClientRequest.emit (events.js:314:20)
    at Socket.socketErrorListener (_http_client.js:428:9)
    at Socket.emit (events.js:314:20)
    at emitErrorNT (internal/streams/destroy.js:92:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)

Unhandled rejections are bad as with Node 14 those will just crash the process.

[acao]

thanks for the bug report! hmmm... which version of the LSP server are you using? are you using the CLI or the server directly or the vscode or vim extensions? seems this is coming from graphql-config since we don't invoke node-fetch ourselves. this error was being trapped before, not sure why it isn't now. Should probably send a client notification instead, so IDE's can push useful warnings about this?

the thing to note here is that without a valid schema, the server can't really do anything, as all language server features require the schema (except formatting which Prettier plugin provides, thus why we don't ship our own formatting handler), so it will need to exit when schema is not present no matter what.

although... i guess because I just implemented auto-reloading when changing the graphql config, it could instead disable all the language server features until the config is changed and a valid schema is present. is that the experience you are expecting?

[rchl]

Starting the server with:

node graphql-language-service-cli/bin/graphql.js server --method stream`

with those dependencies:

    "graphql": "^15.0.0",
    "graphql-language-service-cli": "^3.0.1"

(also tried the latest version from master)

It looks like the problem is indeed in graphql-config and looks like you can't catch that error in here even if you tried.

I suppose I should file an issue on graphql-config repo.

although... i guess because I just implemented auto-reloading when changing the graphql config, it could instead disable all the language server features until the config is changed and a valid schema is present. is that the experience you are expecting?

That sounds better to me then exiting the server as exiting would be hard to understand for the user.
To notify the user about the problem with loading schema, you could probably use window/showMessage. Or create diagnostic in opened gql file, I guess.

[acao]

I was wrong, we can trap any exception we need to and handle this from the server and send a client notification as we should