"`this.splice()` is not a function" error on `vscode-graphql` startup

[VictorGaiva]

My VSCode plugin is failing to start, logging the following error:

8/1/2022, 11:58:03 AM [1] (pid: 32510) graphql-language-service-usage-logs: WARNING: graphql-config error, only highlighting is enabled:
this.splice is not a function

and

[Error - 12:05:13 PM] Request textDocument/completion failed.
  Message: Request textDocument/completion failed with message: this.splice is not a function
  Code: -32603 

This is my current .graphqlrc.yml

schema: "http://localhost:4000/_introspect"

maybeValue: T
config:
  enumsAsTypes: true
  useTypeImports: true
  nonOptionalTypename: true
  scalars:
    Time: number
    DateTime: Date
    Json: Record<string, unknown>
generates:
  app/types/apollo.gql.d.ts:
    plugins:
      - typescript-apollo-client-helpers
  app/types/schema.gql.d.ts:
    documents: "**/*.gql"
    plugins:
      - typescript
  app/:
    documents: "**/*.gql"
    preset: near-operation-file
    presetConfig:
      baseTypesPath: "types/schema.gql.d.ts"
      extension: .gql.d.ts
    plugins:
      - typescript-operations
      - typescript-react-apollo

The same setup was working up to last Friday, and is still working on my colleagues machines.

[acao]

@VictorGaiva apologies there may have been an issue with a revert and thus the publish that happened today. Let me take a look here ASAP

update: i'm not certain where this.splice() comes from.. I think it could be graphql-config?

Either way, I haven't been able to reproduce your bug yet unfortunately, tried several times with a clean local build and the marketplace version. The only config here that our LSP is picking up is schema as far as I understand, so I'm hoping I will be able to reproduce this bug somehow!

[acao]

@VictorGaiva I'm guessing you're on latest 0.7.0? are your colleagues on that version as well? no one is on the (outdated) prerelease version?

I just want to confirm whether this is an issue with the latest release.

[acao]

@VictorGaiva another question - is there anything different about your local environment vs your colleauge's environment that may cause an introspection query to fail? because I can't reproduce this bug with any build configuration or version. Does playground or graphiql or another graphql client tool work with the same localhost:4000/_introspect address? I'm assuming you are using Absinthe or some fancy Elixir framework?

[VictorGaiva]

@VictorGaiva I'm guessing you're on latest 0.7.0? are your colleagues on that version as well? no one is on the (outdated) prerelease version?

I just want to confirm whether this is an issue with the latest release.

Just tested on my colleague computer and the plugin version was outdated. It broke too after updating. I answer the next questions in more comments. Just a second.

[VictorGaiva]

Another quirky of my setup is that it has 2 different GraphQL types of files.

• .graphql "legacy" files that might no be "correct". Example: Int when a Int! is required by the server.
• .gql files are always correct, and being used to generate Apollo Hooks.

The schema is being fetched using the special endpoint _introspect, which doesn't validate the user's authorization header, but only allows one type of request.

Elixir implementation of the endpoint

defmodule Gateway.Schema.Introspection do
use Phoenix.Controller

@introspection """
query IntrospectionQuery {
  __schema {
      queryType { name }
    mutationType { name }
    subscriptionType { name }
    types { ...FullType }
    directives { name description locations args { ...InputValue } }
  }
}

fragment FullType on __Type {
  kind name description
  fields(includeDeprecated: true) {
    name description args { ...InputValue }
    type { ...TypeRef }
    isDeprecated
    deprecationReason
  }
  inputFields { ...InputValue }
  interfaces { ...TypeRef }
  enumValues(includeDeprecated: true) { name description isDeprecated deprecationReason }
  possibleTypes { ...TypeRef }
}

fragment InputValue on __InputValue {
  name
  description
  type { ...TypeRef }
  defaultValue
}

fragment TypeRef on __Type {
  kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } }
}
"""

def introspect(conn, _params) do
  query = conn.body_params["query"]

  if query != nil and String.starts_with?(query, "query IntrospectionQuery") do
    @introspection
    |> Absinthe.run(Gateway.Schema)
    |> case do
      {:ok, data} -> json(conn, data)
      {:error, message} -> put_status(conn, 500) |> json(%{error: message})
    end
  end
end
end

[VictorGaiva]

I validated/rewrote the static query being sent by the plugin to the server, after this issue started.

[acao]

ok! thank you, this is all very helpful to know, I will see if I can reproduce the issue with this new information! i'm sorry the extension broke for them. I might even just be able to delete the version, reproduce this, and re-try

update:

reproduced it finally! ok I hope to have a fix by tomorrow but maybe tonight if I can get it done before 2am here haha. very sorry for this bug!

[acao]

the only this.splice in the main esbuild bundle where I can reproduce is in cross-undici-fetch, which makes sense because this happens when the schema introspection fetch fails. so graphql-config or it may have had a bug since the last release. let me try just backporting to see what this is

[acao]

cross-undici-fetch is still failing and I don't know why :((

@dotansimha I'm guessing it's one of the SchemaLoaders graphql-config is using?

Update:

some clues

• graphql-config was resolving to 4.3.0 in both the last release (that worked for your colleages) and this one.
• that said, it's dependencies are resolved to different versions in the lockfile

some findings

• upgrading graphql-config to 4.3.3 causes some terrible esbuild failures 😢 it fails trying to import ts-node into the bundle?! 👀

[acao]

I finally got schema fetch working, just had to pin cross-undici-fetch 🤷🏻‍♀️

"resolutions": {
    "cross-undici-fetch": "0.1.20"
  }

[acao]

ok, #2624 should fix this for vscode-graphql users and beyond. it would appear this even impacts (n)vim coc users with introspection url for schema config

[acao]

oooh this is some npm ^ resolution madness haha!

so, even though we are pinned to the same [email protected] version, the @graphql-tools/url-loader package resolves to a much better new version that doesn't use cross-undici-fetch at all!

sorry for the deep dive @VictorGaiva , just going into these details because I tagged some colleauges who maintain these libraries. I will let you know when the fix is ready for you and your colleauges

[acao]

0.7.1 should be the fix version! confirmed it works with the bundled version.

let me know if there are still any issues and I can re-open this!

[acao]

I will just keep it open for a bit just in case someone gets this bug in between updates again.

[acao]

tested it from the marketplace again with introspection, gql files, everything looks good now!

[VictorGaiva]

Updated it and it now works just fine. Thanks @acao \o

[acao]

Fantastic to hear the confirmation! I have more plans to improve the introspection schema user experience. For example, it seems there is still the issue with the cached SDL file not updating. Many more features coming soon but we will use pre-releases to avoid this happening again.

I have an elixir side project using Mobilizon, it such a neat runtime! Happy graphql-ing!

[acao]

Looks like this one came back as #2662 so I'm bringing the conversation back here where there is more context and easier to find title for the error. hope to fix it by returning to this fix tonight

[acao]

ok, latest release should fix it. so much follow up to do