[graphql-lsp] Template string fragment get Unknown fragment error

[VinceBT-BG]

When inserting a fragment inside a template string, the fragment does not get recognized when it gets called in the rest of the gql string

IDE: VSCode 1.75.1

Extensions:

• GraphQL: Language Feature Support v0.8.5
• GraphQL: Syntax Highlighting v1.0.6

[avlaguta]

The related issue:
#2064

[acao]

there must have been a change that broke this use case. it works if the fragments are in a separate file, or are defined in the same graphql string, which is what the tests cover

[acao]

Huh, I can't seem to reproduce the bug now, is it fixed for you in the latest version?

[VinceBT-BG]

I tried to reproduce your example and I don't have the same result, can you show your config/schema ?

PS: I am on MacOS Ventura 13.4.1, using

• GraphQL: Syntax Highlighting v1.2.2 (latest)
• GraphQL: Language Feature Support v0.8.16 (latest)

[acao]

@VinceBT-BG here is the config:

export default {
   schema: "src/schema/schema.graphql",
   documents: "src/queries/**/*.ts",
};

and a very simple schema for testing purposes:

# for example
type ExampleType {
   shelter: String
   something: String
   however: String
}

type Query {
    exampleField: ExampleType
    love: String
    message: String
}

the syntax highlighting isn't relevant here to be clear, this is a bug you're having with the LSP server, but what I'm guessing is that the documents config isn't provided?

[VinceBT-BG]

I was indeed using schemaPath instead of schema in the configuration! I tried on the example and it worked, I also tried in my project and I don't have the errors anymore, thanks !

EDIT:

Indeed when using schemaPath, in order for the fragments to work, the files need to be specified in an includes field, whereas if schema is present, it will work if placed in documents instead.

[acao]

@VinceBT-BG music to my ears! another happy user. I will add something to the FAQ section for users using legacy schemaPath

awesome gif tool by the way, i like the keyboard icons, maybe I will use this!

[Crunchyman-ralph]

I'm still having this issue:

fragment file:

import { gql } from '@sb/webapp-api-client/graphql';

export const processTestItemListQuery = gql(/* GraphQL */ `
  query processTestItemListQuery {
    allProcessTestItems(first: 100) {
      edges {
        node {
          ...processTestItemListItemFragment
        }
      }
    }
  }
`);

export const processTestItemListItemDeleteMutation = gql(/* GraphQL */ `
  mutation processTestItemListItemDeleteMutation($input: DeleteProcessTestItemMutationInput!) {
    deleteProcessTestItem(input: $input) {
      deletedIds
    }
  }
`);

export const processTestItemListItemFragment = gql(/* GraphQL */ `
  fragment processTestItemListItemFragment on ProcessTestItemType {
    id
    name
    price
  }
`);

.graphqlconfig:

{
  "name": "Untitled GraphQL Schema",
  "projects": {
    "api": {
      "name": "GraphQL API",
      "schema": "packages/webapp-libs/webapp-api-client/graphql/schema/api.graphql"
    },
    "contentful": {
      "name": "Contentful API",
      "schema": "packages/webapp-libs/webapp-contentful/graphql/schema/contentful.graphql"
    }
  },
  "documents": "**/*.ts"
}

[ypresto]

@acao I still have same issue now. Should I create new issue or could you reopen this issue? 🙏

[acao]

@ypresto can you open a new issue, and please provide the config? if it's a multi project config then it's a different bug with the same message

[joshmedeski]

Adding "documents" to my config file worked, thanks!

[sachingaikwad123]

I am still facing this issue in my vscode. Here is my graphql-config:

{
"schema": "http://127.0.0.1:8000/graphql/",
"documents": ["src/**/*.{ts,tsx}"]
}

My fragment is defined in another file.

Q: Is there any solution for this?

VSCode version: 1.86.2
GraphQL: Language Feature Support: 0.9.1
vscode-graphql-syntax: 1.3.2

[acao]

@sachingaikwad123 can you see if the pre-release in #3521 fixes the issue? we have tests that I think should confirm this issue is resolved.

what I discovered was we were updating the fragment cache for onUpdate and onWatchedFilesUpdate, but not on onOpenOrAdd, and some other issues with fragment cache keys that piled up along the way. now we have an integration test suite for the server that confirms a happy path for validating fragments and fragments on queries across changes to all files. i will double check to make sure we are still confirming validation is empty where it should be on every mutative event

[matheusAle]

hey! having the same issue as @sachingaikwad123

@acao I switched to the pre-release and now the option extensions.languageService.enableValidation: false is working 🎊

also, the go to fragment definition is working partially, it's opening the file where the fragment but the cursos do not go the the definition line.

[acao]

The only thing i want to clarify here with the incoming fix is that we are not inferring information from template string expressions. If a fragment is present in any file in the project, it can be used in any query, and it's up to the client framework to decide how to resolve fragments

[xkelxmc]

Same problem with using separate files

[efstajas]

I'm running into the same issue now. I have a lot of fragments defined within .svelte files in a "context="module"" script block, but I don't think this should make a difference. I include all .ts and .svelte files in my documents. When I save or edit files, every now and then it starts picking up the fragments and the error disappears, though I haven't really been able to see a specific pattern as to when this happens.

Here's my config:

schema: 'src/lib/graphql/__generated__/schema.graphql'
documents: 'src/**/*.{graphql,js,ts,svelte}'
ignoreNoDocuments: true

[acao]

i have a theory this bug has resurfaced because of another schema cacheing bug I've been working on - thus the fragments are "Unknown" because their base type is missing

[efstajas]

@acao if it helps — i've noticed since that pretty consistently the error disappears when i:

• save the file that has the schema in question (even without any changes)
• save the file in which the error occurs (also without changes)

after that, it seems like pretty much 100% of the time, the error disappears for all the fragments defined in the 1st file.

[guneyozsan]

We have all the fragments in different files. Only one of them has the issue where all have similar structures.

I couldn't notice a pattern how it happens. There were no issue until some point (see downgrade not below). Then some files previously working fine started displaying red marks without any modifications.

• Downgrading "GraphQL: Language Feature Support" from 0.11.0 to 0.9.3 resolves the issue.
• Reinstalling 0.11.0 revives the issue on the same fragment.
• Saving with or without changes does not help.

[yamatsum]

@acao Is there a plan to fix this bug?

[brentshulman-silkline]

@acao if it helps — i've noticed since that pretty consistently the error disappears when i:

• save the file that has the schema in question (even without any changes)
• save the file in which the error occurs (also without changes)

after that, it seems like pretty much 100% of the time, the error disappears for all the fragments defined in the 1st file.

Exactly the same for myself

[acao]

@yamatsum yes it was one of the goals of the last refactor, but the test cases I resolved for don't seem to cover some of these cases. if someone could provide a test case for MessageProcessor.spec.ts that re-creates this reliably it would be awesome!

[richard-stafflink]

A college (MAC) has the same issue, but I don't (Linux) for the same codebase.
Interestingly, some fragments are recognised, some not, so not a consistent problem.
What's more interesting is that one particular fragment is recognised in one file, but not in another - Strange!