Issue with bundling undici in esbuild on upgrade to vscode 1.66

[peteole]

Actual Behavior

The server crashes when using an API endpoint to specify the schema.

Expected Behavior

The extension fetches the API schema from the endpoint via introspection

Steps to Reproduce the Problem Or Description

create a graphql.config.yml with the following content:

schema:
  - https://huddle.hsg.fs.tum.de/api/query

The endpoint itself works fine as you can see here: https://huddle.hsg.fs.tum.de/api

Specifications

• GraphQL for VSCode Extension Version: 0.3.53
• VSCode Version: 1.66.0-1
• OS Name: manjaro linux
• OS Version: plasma 5.24

Logs Of TS Server || GraphQL Language Service

GraphQL LSP restarted
(node:433184) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `code --trace-warnings ...` to show where the warning was created)
3/31/2022, 10:12:36 PM [3] (pid: 433184) graphql-language-service-usage-logs: {"type":"usage","messageType":"initialize"}
/home/olep/.vscode/extensions/graphql.vscode-graphql-0.3.52/out/server/server.js:96572
            if (socket[kParser].timeoutType !== TIMEOUT_IDLE) {
                                ^

TypeError: Cannot read properties of undefined (reading 'timeoutType')
    at _resume (/home/olep/.vscode/extensions/graphql.vscode-graphql-0.3.52/out/server/server.js:96572:33)
    at resume (/home/olep/.vscode/extensions/graphql.vscode-graphql-0.3.52/out/server/server.js:96542:7)
    at connect (/home/olep/.vscode/extensions/graphql.vscode-graphql-0.3.52/out/server/server.js:96531:7)
[Info  - 10:12:37 PM] Connection to server got closed. Server will restart.
[Info  - 10:12:37 PM] The graphql server has stopped running
[Info  - 10:12:37 PM] The graphql server has stopped running

[Jose4gg]

+1 here

[acao]

I hope to take a look this weekend

Update: some terrible things went down over the weekend and it will be a few weeks before I can look

[dmastrorillo]

Still getting this on v0.3.53. Any updates?

[acao]

I tried this weekend and could not recreate this bug 🤷🏻‍♀️

[peteole]

You mean the schema loaded as expected or something else went wrong?

[acao]

yes, the schema loaded and the extension worked fine

[TheAsda]

Just installed the extension

[arcanis]

As a data point I also have this issue, and the exact same setup used to work. Perhaps something to do with the VSCode version? The 1.66 has been quite unstable for me in other places.

[acao]

0.4.0 was just released from the monorepo! We removed op execution for now, we will reccomend another extension for op exec soon

this version works for me. You can also test in this repo with these instructions:

1. checkout graphiql, open in vscode
2. yarn
3. run „launch extension“ task in vscode

[peteole]

Upgrading to 0.4.0 made no difference for me

[kellertobias]

Having the same issue. Loading from a nestjs graphql endpoint (also on 0.4.0, same happening in 0.3.53)

[GiyoMoon]

Same issue here :/
The extension is on 0.4.0 and vscode on 1.66.0

[jablonski]

Same error here... it was working fine before updating to VSCode 1.66.0.

[acao]

hey @orta - we published your rewrite of the extension, and it seems users are having issues. Do you know what could be the issue?

[acao]

I have now reproduced the bug finally, but the last time I ran this extension in the repository it worked (this weekend). Terribly sorry for this, I will see what I can figure out.

it appears to be a bug coming from the underlying vscode-languageserver

[acao]

well that's interesting! it appears that disabling the esbuild step entirely fixes the problem for now?

I just published 0.4.1 which should contain this as a fix, though the extension will be gigantic until i figure out a better bundling strategy with esbuild

I would prefer to use pre-releases, but in order to use vsce with yarn workspaces, I need to use an old forked version of vsce based on a PR that doesn't contain the --pre flag :(

[V-ed]

Confirmed to work back again for me in 0.4.1 in vscode 1.66.0!

Extension size does not really annoy me as long as everything seems to be in working order, I won't say no to optimizations though :)

Even the extension's activation time didn't really change (22ms -> 29ms, which I don't consider major and falls under hardware variations at this point)

Thanks for looking into this!

[jablonski]

Works for me too again... thank you!

[suppayami]

Works for me too, thank you :D

[acao]

so happy that it's fixed for everyone!

still considering this unresolved, as the workaround cannot be permanent for obvious reasons, the extension is now 8-12x larger than it needs to be! we had been using esbuild for some releases before as suggested by vscode.

it seems a lot of users here have noticed this error ocurred when upgrading to [email protected], correct? perhaps something changed in the underlying vscode runtime that causes an issue when inlining undici (a really stellar module imho)?

socket[kParser].timeoutType !== TIMEOUT_IDLE

with graphql-config's @graphql-tools/url-loader dependency which uses undici, we may be resolving a new version which builds differently as well, or perhaps the combination of the new vscode release and this dependency change caused it?

Either way, I can't seem to find a way to a working esbuild bundle for the extension, but will keep testing locally until I find one

also, to be clear, this had nothing to do with @orta's changes, and was an oversight possibly caused by my not testing the extension when making dependency changes.

Once I finish the migration, and fix this bundling bug, we can write a proper test suite for this extension!

[acao]

Ok so, the working resolution appears to involve rolling back esbuild by a minor version. The same version of undici has no problem being bundled with this version of esbuild, in the latest vscode version