[lsp-server] vscode-graphql triggers large amounts of requests to my graphql server for bulk file change events in 0.11.0

[Slessi]

Current Behavior (if applicable)

When I use graphql-codegen to generate types from my schema whilst VSCode is open, vscode-graphql automatically sends tens or hundreds of requests to my backend server to get the introspection schema.

In this video, I have two terminals running. Top terminal is my backend server which prints a log everytime it receives a request. Bottom terminal is me just generating types with graphql-codegen. You will see on 0.11.0 my backend server gets spammed, but on 0.9.3 it does not.

Untitled.mp4

Desired Behavior

A change to my generated types should not cause vscode-graphql to need to re-request introspection information. If it does, it should certainly not need to do it more than once.

My graphql.config.cjs:

module.exports = {
  projects: {
    default: {
      schema: ['http://localhost:8080/graphql'],
      documents: ['src/**/!(*.d).{ts,tsx}', '!src/types/graphql.ts'],
      extensions: {
        codegen: {
          hooks: {
            afterOneFileWrite: ['prettier --write --ignore-path=.prettierignore'],
          },
          config: {
            withHooks: true,
            withHOC: false,
            withComponent: false,
            avoidOptionals: {
              field: true,
              inputValue: false,
              object: true,
              defaultValue: true,
            },
            scalars: {
              Time: {
                input: 'Date | string',
                output: 'string',
              },
            },
          },
          generates: {
            'src/types/graphql.ts': {
              plugins: ['typescript', 'typescript-operations', 'typescript-react-apollo', 'fragment-matcher'],
            },
          },
        },
      },
    },
  },
};

[acao]

@Slessi looking into this today, the new schema polling should not be behaving like this on watch events. Something is resetting the schema cache for every watched file change, and it should not be

[acao]

update: I've churned on it some this afternoon and I think the lru-cache invalidation needs more work because of the file watching/mass file change case I hadn't considered. Luckily the new integration tests I've added helped me spot regressions for the cache lifecycle in one approach to this bug that I've tried. If I can't find a solution by mid day tomorrow, maybe sooner, I may just remove the new lru-cache based schema polling cache invalidation logic and patch 0.11.x until I can make sure it's working properly for the mass watched file changes case - which is not just an issue for users of graphql-codegen, but any other codegens for frameworks in other languages, or even codegens which are unrelated. I imagine the same bug happens with a git pull and a huge upstream diff.

I added this feature at the end of preparing this release, and only tested with editor file changes (oof), but it's actually quite small to remove and only one of many improvements 0.11.x offers

[acao]

I have an update! I've identified what might be the true source of the issue, which is MessageProcessor.cacheConfigSchemaFile() - this method is what re-writes the cached SDL file for mixed/network schema config scenarios, and it just needs to be debounced, along with ensuring the debounce-ish effect of the short TTL schema LRU cache, hoping to have a working fix tomorrow as I juggle a few unexpected disruptions this week

[acao]

today I'm working on manually re-creating exactly this bug with a decently sized project, instead of just mimicking it, so I can be sure we have a proper fix. sorry it's taking so long!

[Slessi]

Hey @acao is there a new version out? I see only 0.11.0 as latest

[acao]

@Slessi thank you for asking, I had overlooked this release error!

https://github.com/graphql/graphiql/actions/runs/10197678455/job/28211011654#step:6:422

Need to fix this and run again!

[dmarkow]

@acao Definitely still happening for me with the latest version (0.11.3). Not nearly as often, but just now my dev API server got hammered with hundreds of introspection requests from the plugin and crashed.

[f-elix]

Same here! Still happening at version 12.0. My server timed out because of all the introspection requests.

[artaommahe]

@acao the issue is still here with v0.12, just killed our backend's pods again doing several types update in a row