GraphQL request are adding field "operationName" which results in a failed call.

[matulkum]

Expected Behavior

The query string should not have the field "operationName" added.

Eg. Supplied query string:

{ assetCollection { total } }

should results in:

{"query":" { \n\t assetCollection { total }\n}"}

Actual Behavior

Insomnia adds the field "operationName" to the query string, which causes the request to fail.

Eg. Supplied query string:

{ assetCollection { total } }

results in:

{"query":" { \n\t assetCollection { total }\n}","operationName":"Operations"}

Reproduction Steps

Just create a new GraphQL request. Normally this does not happen. But it some point insomnia will start to add this field. And ones it does it keeps adding it all the time.

I do not see anyway to get it to work again, besides deleting the whole request entry and create it completely from scratch.

Is there an existing issue for this?

• I have searched the issue tracker for this problem.

Additional Information

No response

Insomnia Version

2022.7.4

What operating system are you using?

macOS

Operating System Version

13.0.1

Installation method

download

Last Known Working Insomnia version

No response

[scottwilloughby]

We are seeing this same issue in 2022.7.2, but not in 2022.7.1

[mkartchner994]

In versions after 2022.7.1, it looks like what is happening is that when using the structured GraphQL query body type, if it is an anonymous operation definition used like:

{
  user {
    name
  }
}

Insomnia is passing the query with operationName as an empty string like:

{"query":"{\n\tuser {\n\t\tname\n\t}\n}","operationName":""}

Whereas in version 2022.7.1 it passes it as null:

{"query":"{\n\tuser {\n\t\tname\n\t}\n}","variables":null,"operationName":null}

The GraphQL spec outlines how GraphQL servers should handle the operationName and specifically calls out the cases as either being null or an operation name defined in the document. So for an anonymous operation definition, I think operationName should either not be passed, or specifically set to null.

[filfreire]

Hi folks, this should be fixed on latest 2022.7.5

[vap78]

I'm still getting this issue.

Version: Insomnia 2022.7.5
Build date: 19.01.2023 г.
OS: Windows_NT x64 10.0.22621
Electron: 22.0.0
Node: 16.17.1
V8: 10.8.168.20-electron.0
Architecture: x64

Request in Insomnia:

query {
	reservations(
		input: {
			driverId: "bd073db9-1de9-4d1c-896c-2a8400e33525"
		}
	) {
		id
	}
}

Actual request sent:

{"query":"query {\n\treservations(\n\t\tinput: {\n\t\t\tdriverId: \"dc8ef8b1-5591-43f7-9732-29a03fa45cb6\"\n\t\t}\n\t) {\n\t\tid\n\t}\n}\n","operationName":"Operations"}

[amalricBzh]

I'm still getting this issue.

Version: Insomnia 2022.7.5
Build date: 19.01.2023 г.
OS: Windows_NT x64 10.0.22621
Electron: 22.0.0
Node: 16.17.1 V8: 10.8.168.20-electron.0
Architecture: x64

Same here. Please reopen this issue !

[tfutada]

Same. It won't work. For some reason, newly created requests are not functioning while existing requests are working properly.

[SteveyPugs]

Just started experiencing this issue after and update:

Version: Insomnia 2022.7.5
Build date: 1/19/2023
OS: Darwin arm64 22.3.0
Electron: 22.0.0
Node: 16.17.1
V8: 10.8.168.20-electron.0
Architecture: arm64

Returns on GQL queries are:

{
	"errors": [
		{
			"errorType": "BadRequestException",
			"message": "No operation matches the provided operation name ."
		}
	]
}

[mamuf]

I can confirm it still happened to me in 2022.7.5. But restarting Insomnia helped eventually...

[joachimbulow]

Creating a new request (NOT duplicating a bugged one) and copying the query/mutation seems to be a workaround

[mhiley]

Creating a new request (NOT duplicating a bugged one) and copying the query/mutation seems to be a workaround

+1. Running 2022.7.5, when duplicating a query, I get the extra "operationName":"Operations" field in the query being sent to the server, which breaks the server. Creating the query from scratch seems to solve it. Another alternative is to use "Copy to Curl", modify the generated curl output, and then paste it into a terminal.

[SteveyPugs]

Creating a new request (NOT duplicating a bugged one) and copying the query/mutation seems to be a workaround

+1. Running 2022.7.5, when duplicating a query, I get the extra "operationName":"Operations" field in the query being sent to the server, which breaks the server. Creating the query from scratch seems to solve it. Another alternative is to use "Copy to Curl", modify the generated curl output, and then paste it into a terminal.

I second this. This seems to have fixed it.

[gkristic-vc]

I wasted time looking for a problem somewhere else, until I realized that it was Insomnia setting this field to Operations.

I can't tell for sure whether this happens only to queries created by duplicating another (although this seems to be the case), but I found a simpler workaround than recreating from scratch or going through curl: Notice the "Operations" label below?

That's the operationName you'll get. Just click it and you'll get a dropdown that already includes the correct query name. Select it and you're done. Now the request will pass this validation on the server side.

Edit: Your query has to have a name for the name to be pre-populated, like query whatever { ... }. If it doesn't, then you'll get an empty list and there's no way to select anything other than "Operations". But Insomnia seems to omit operationName when you have an anonymous query anyway, so it's not a problem.

[washanhanzi]

I wasted time looking for a problem somewhere else, until I realized that it was Insomnia setting this field to Operations.

I can't tell for sure whether this happens only to queries created by duplicating another (although this seems to be the case), but I found a simpler workaround than recreating from scratch or going through curl: Notice the "Operations" label below?

That's the operationName you'll get. Just click it and you'll get a dropdown that already includes the correct query name. Select it and you're done. Now the request will pass this validation on the server side.

Edit: Your query has to have a name for the name to be pre-populated, like query whatever { ... }. If it doesn't, then you'll get an empty list and there's no way to select anything other than "Operations". But Insomnia seems to omit operationName when you have an anonymous query anyway, so it's not a problem.

Version 2023.1.0, the Operations list is empty, but I just clicked it, and it works. Thank you.

[arsonx]

Version 2023.1.0, the Operations list is empty, but I just clicked it, and it works. Thank you.

It also worked for me. Thanks!

Would like to summarise.. One need to select a blank field from empty dropdown. If not "operationName":"Operations" is still being sent. I would still consider this as a bug.

[Sceat]

It also prevent the schema from being fetched as the introspection query contains Operations

[xarses]

Also seeing this in 2023.4.0. After reading this, it appears to be that it only occurs when duplicating a query, but not always. Duplicating the source again has a chance of succeeding.

@filfreire Can we re-open this or would you like a new issue?

[filfreire]

@xarses if possible please create a new issue. If you have any screenshots or recordings of this issue happening that would be helpful. Thank you in advance!

[kunwardeep]

I was able to fix this by picking a name from the dropdown next to the schema

[mattiasflodin]

Clicking the "Operations" text either does nothing or shows an empty popup window. I don't see any way of changing it.

[borys-p]

This is still happening and can be easily reproduced, could be an edge case left over.

First, send a GraphQL query with an operation name (can be anything), the query will succeed as the OperationName in the JSON payload matches what's in the GraphQL query. Now, remove it from the query and try again. Boom, you get a server error, because the app did not remove OperationName from the JSON.

I'm testing with the most recent 8.6.0 version.

cc: @filfreire

[anatelli10]

This caused me a lot of trouble. I'm on v8.6.1. bump

edit: Don't quite have the time to look into the bug report here and all the comments, but my experience has been:

1. When sending an unnamed query, operationName will default to "Operations" (it shouldn't default to anything)
2. After sending a named query, the UI's operation name display can become out of sync with the actual operationName in the payload. When editing the name of the query in the text editor, the UI's syncing is inconsistent.

Apologies if this is considered a separate issue, please consider looking into this. It basically makes GraphQL unusable in Insomnia, which I think should be treating GQL as a first class citizen. In fairness of not opening a new issue, the "Operations" default string is still lingering.

cc @filfreire