[lsp-server] 🐞 VSCode validation error Unknown fragment in v0.11.0

[minami-minami]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I get errors after updating “GraphQL: Language Feature Support” to v0.11.0.

• FooFragment is defined another file.
• No errors if defined in the same file.

Expected Behavior

No errors when using fragments from another files.

Steps To Reproduce

1. define fragment
2. define query or fragment in another file.
3. use fragment defined in step 1

Environment

• LSP Server Version: latest
• OS: macOS 13.5.1
• LSP Client: VSCode v1.89.1
• graphql: v16.8.1

Anything else?

No response

[sbiallas]

I have the same problem. I use GraphQl-Codegen with the client preset, which works as expected. I get syntax highlighting and autocomplete options inside the gql tags. But when I use fragments from other files their are not recognized. I had these fragments also working, also with the fragment names showing up as autocomplete options, but I can't reproduce it. When I rename the generated gql tag to e.g. graphql and adjust the imports suddenly the errors disappear and I get also the right autocomplete options, but after next reload of vscode the errors are there again and autocomplete stops working. I got error messages inside the LSP output for I guess every file which contains a gql tag:

[jordanweaver]

I also noticed this behavior and it was even more subtle in my case... all I had to do was simply open the file containing the fragment and then the error disappeared in the file/query where the fragment was spread. But it would come back with any reload or edit.

Not sure how recommended it is, but I opted to manually downgrade through VS Code's extension manager, where it seems 0.9.3 was the last version prior to 0.11.0:

[sbiallas]

I also noticed this behavior and it was even more subtle in my case... all I had to do was simply open the file containing the fragment and then the error disappeared in the file/query where the fragment was spread. But it would come back with any reload or edit.

Not sure how recommended it is, but I opted to manually downgrade through VS Code's extension manager, where it seems 0.9.3 was the last version prior to 0.11.0:

Did the same and worked for me!

[VinceBT-BG]

This is kind of a breaking bug, all fragments have broken in my project as well

[pronovaso]

Confirm same bugs as mentioned here.

[jaredellison-nyt]

Confirming I'm seeing the same bug as well. Adding a plain text version of the logged syntax errors to help others find the github issue.

Reverting to GraphQL: Language Feature Support v0.9.3 resolves the issues.

[Info  - 10:14:19 PM] {"type":"usage","messageType":"initialize"}
GraphQL LSP restarted
[Info  - 10:14:20 PM] Could not parse the TypeScript file at file:///path/to/file.ts to extract the graphql tags:
[Info  - 10:14:20 PM] SyntaxError: Unexpected token, expected "," (2:55)
[Info  - 10:14:20 PM] Could not parse the TypeScript file at file:///path/to/another/file.ts to extract the graphql tags:
[Info  - 10:14:20 PM] SyntaxError: Unexpected token, expected "," (2:47)
[Info  - 10:14:20 PM] GraphQL Language Server caches initialized

Thanks for the work on this extension, beyond this bug it's an invaluable tool!

[ionTea]

Same issue as here and it's fixed by downgrading to v 9.3.

This is what I found - I get the error where the file containing the fragment couldn't be parsed

[Info - 9:39:01 AM] Could not parse the TypeScript file at <...filepath.ts> to extract the graphql tags:
[Info - 9:39:01 AM] SyntaxError: Unexpected token (4:4)

When I then go to that file and save it, and then go back to where I used the fragment the fragment is picked up and it's working again. I'm guessing the file is parsed successfully and cached when I save the file or something?

[dulnan]

While I seem to have a slightly different setup than others, I also encountered a similar issue and I was able to figure out what's causing it in my case. I still had some .graphql files that contain import comments at the top of the file, e.g.

#import "~/components/Teaser/fragment.teaser.graphql";

Looking at the logs (in neovim using :LspLogs in my case), the error I saw was:

[ERROR][2024-08-01 11:20:22] ...lsp/handlers.lua:623
"AggregateError: Failed to find any GraphQL type definitions in: ./node_modules/blokkli-beta/dist/**/*.graphql;\n - 
Cannot find module '~/components/Teaser/fragment.teaser.graphql'\nRequire stack:\n- /run/media/dulnan/Storage/development...

Since I don't need these import comments anymore, I was able to remove them. I assume this functionality to resolve these imports was added at one point or it was made to throw an error if the import fails. In my case, the imports are irrelevant anyway because all the documents that could potentially be imported are declared as a pattern in documents, so their fragments are available even without the import.

[DerPlayer2001]

Is there any Progress on resolving this Issue in the Current Version?

[acao]

@DerPlayer2001 not yet, I will let folks know here when it is!

update: still trying to find a job, I will get to this once I do

[vermario]

Same issue here, only downgrading to 0.9.3 fixes it

[acao]

Emergency situation: With the recession in Germany, I was caught up in a 30% engineering org layoff in the summer, and without being able to find a job, lost my apartment and had to move back to the US a few weeks ago. I have to prioritize at least some income before I can jump back into open source work.

Meanwhile, as always, PRs are welcome, even a draft PR that adds a failing test case, as re-creating a bug like this is very hard and time consuming, and is the main reason I haven't been able to solve this. You can use the new functional spec suite for MessageProcessor, which is designed to model real workflows and project configurations, including several scenarios like these.

[DerPlayer2001]

@acao

Meanwhile, as always, PRs are welcome, even a draft PR that adds a failing test case, as re-creating a bug like this is very hard and time consuming, and is the main reason I haven't been able to solve this. You can use the new functional spec suite for MessageProcessor, which is designed to model real workflows and project configurations, including several scenarios like these.

So u need a minimal project that exhibits this issue? I don't think this Issue results in failing tests, but in errors in the Intelisense of VSCode (at least that's the case in our Projects). If needed I could provide such a project.