insomnia: Graphql error - Unknown operation named \"Operations\"

Expected Behavior

I passed the url and method I wanted to make the request, he asks that he needs the “operations” method

{ "errors": [ { "message": "Unknown operation named \"Operations\".", "extensions": { "category": "graphql" } } ] }

image

Actual Behavior

When I make a request it does not return the content that should be returned

Reproduction Steps

No response

Is there an existing issue for this?

Additional Information

This problem happened in the new update that happened, at the moment everything was normal

Insomnia Version

2022.7.5

What operating system are you using?

Ubuntu

Operating System Version

Ubunut 22.04.1

Installation method

apt-get

Last Known Working Insomnia version

2022.7.4

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 27
  • Comments: 59 (2 by maintainers)

Most upvoted comments

Clicking here before “Send” resolves the issue…

image

To me, this indicates it’s a UI issue. Meaning, when you’re typing, the operationName stored in the state is being updated, but sometimes the last character you type doesn’t make it into the state, so “Send” sometimes sends without the last character (or change). If you explicitly select the operationName from the drop-down, then it passes it in full.

Interestingly, the complete operationName is being extracted and getting into the drop-down ok.

@mislav 👋 nice to see you around here!

I’ve also been running into a similar problem lately. Does clicking on operations and selecting the empty row work for you?

image

Still reproduces on 2023.2.0

image

Similar error, but slightly different error message: No operation named ""

It happens when I’m trying to execute an unnamed query against the GitHub GraphQL API: {viewer{login}}. This is a perfectly valid GraphQL query. But Insomnia serializes the API requests into JSON as:

{"query":"{viewer{login}}","operationName":""}

The problem is the empty operationName parameter, which Insomnia shouldn’t have added unless my GraphQL document has multiple named operations and my cursor is within one when I press “Send” in Insomnia.

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

I can confirm that the issue is still there, version 2023.5.7 I find a workaround duplicating one of the request that works, and then named the query ‘X’

query x {
	clients {
		id
		nit
		billingEmail
		clientType
		
	}
}

And the issue is still there image

I does not “solve” the issue - it is a way to avoid it until it is solved. Turning off features to enable other features to work is not a solution.

As of this moment it’s still not fixed for me with the latest update:

Version: Insomnia 8.4.2 Build date: 11/15/2023 OS: Darwin x64 22.6.0 Electron: 27.0.3 Node: 18.17.1 Node ABI: 118 V8: 11.8.172.16-electron.0 Architecture: x64

As a workaround, giving names to my mutations at least allows me to keep working.

Why in the world was this terrible straight-up bug closed? We have several people hitting this constantly. On v2023.5.8 and still happening.

A workaround that seems to consistently work for me:

  1. Change from GraphQL to JSON
  2. Remove ,"operationName":"Operations" from the end of the query
  3. Send query (it should work now)
  4. Switch back to GraphQL and try again

This page in the Insomnia docs gave me the idea with: Note: It may be useful to know that this is how Insomnia stores the request body behind the scenes. Try converting the body type to JSON and back and see for yourself.

Screenshot 2023-12-27 at 12 05 45 AM Screenshot 2023-12-27 at 12 06 11 AM

@colinshum 👋 Selecting the empty row item does work; good find!

My workaround was to always ensure that an operation is named in my query, but when executing named operations, I sometimes run into the same issue that was also reported in this thread: that Insomnia sends an incomplete or outdated operation name to the server. For instance, I might rename my operation to test, but when executing the query, the server responds with unknown operation named "tes". It feels as if whatever GraphQL parser Insomnia uses to extract operation names, it does not do its job well.

@cwalworth Cameron, that’s a really good idea, and thanks for showing h ow you worked it out.

I find this whole situation hard to imagine, if these Kong people are serious. They’ve taken forever to make an fix, and then somehow it seems people aren’t getting it. Along with too-‘clever’ hacker-looking identities and ‘chinese’ code traps.

Here’s what I did, considering that originally this was good work, by decent persons.

  • I removed Insomnia completely
  • downloaded the latest and installed

Then I was met with one more set of requirements.

I’d really suggest there needs to be some rethinking at Kong, and hope they do it.

It seems like the issue is still here with Insomnia v8.4.2 on MacOS ( node 18.14.2 )

I don’t really understand why this Operations feature was added. What does it solve?

Seems to me it mostly confuses users and causes bugs. Typically I use insomnia configurations generated by automation tools so the Operations are split into separate requests and the Operations selector is never set so nothing works.

Same problem for me as well for a while:

Version: Insomnia 2023.2.2
Build date: 5/17/2023
OS: Darwin arm64 22.5.0
Electron: 22.0.0
Node: 16.17.1
V8: 10.8.168.20-electron.0
Architecture: arm64

Same version as @Nitrodist , with the same error, and the same observation about the named panel being “Operations”. If I click on that, it’s an empty dropdown.

To fix the problem, I was able to get around it by creating a new query, then copy and pasting information into it. Then it will work again, until it randomly doesn’t.

Every named query I run does this. If you copy the request as cURL you can see that the operationName in the body does not match the query name. It seems like there’s a state issue in insomnia where it sets the operationName to whatever it was before the last keyup event. It’s been happening for a while, though all of the current beta releases and even in some of the stable releases leading up to the beta.

You can see it reflected in the UI too:

Screenshot 2023-03-08 at 10 53 36 AM Screenshot 2023-03-08 at 10 54 32 AM

Downgrading to 2022.7.2 works, if you update the name of the query to cause it to update the operationName. Version picked somewhat arbitrarily, this issue seems to have been introduced some time late last year, older versions don’t have the problem.

Clicking here before “Send” resolves the issue…

Yes, that works Hard to imagine how they’ve left this broken, as of 2022.7.5, still the download.

Thank you, @philwhln

@cwalworth Just got your reply, thanks for that. And you’ll see I put a few more things for the case…

I’ll have a look at Insomnium, and maybe the fix here could be ported, as it’s pretty small.

Take care, and hope you’re enjoying nice holidays 🌲

@narration-sd I completely agree, which is why I’ve been using Insomnium:

Insomnium is a fork of [Kong/insomnia at 2023.5.8](https://github.com/ArchGPT/insomnia), the last commit before compulsory account login was introduced. In a sense, Insomnium is a community response to [the latest product update that forces account creation w/o warning](https://news.ycombinator.com/item?id=37680522).

Unfortunately this bug came with the fork, but at least I don’t have to sign in!

still not fixed 8.4.5 macOS apple silicon

Still having the same issue with Insomnia 8.4.5 on Ubuntu.

Screenshot 2023-09-26 at 16 47 09 I think it’s not an issue anymore

+1 And the issue is still there

This only seems to happen if you switch between named and unnamed queries with “Automatic Fetch” enabled. The easiest workaround is to exclusively use named or unnamed queries.

The other option is to select the empty operation name or setting a bogus name for the query and selecting the same from the operations tab 🤷.

image

image

The error is still happening on 2023.2.2 😕

Screenshot 2023-05-30 at 13 45 14

I got the same error today after updating Insomnia to the latest version!

Clicking here before “Send” resolves the issue…

image

To me, this indicates it’s a UI issue. Meaning, when you’re typing, the operationName stored in the state is being updated, but sometimes the last character you type doesn’t make it into the state, so “Send” sometimes sends without the last character (or change). If you explicitly select the operationName from the drop-down, then it passes it in full.

Interestingly, the complete operationName is being extracted and getting into the drop-down ok.

Similar issue with me when adding the query name, it was cutting off the last letter - selecting this drop down and clicking the name seemed to help get around the issue

We hit this too. Insomnia is removing characters from the extracted operationName

query Test123456789 {
  fake {
    id
  }
}

Looking in the Timeline on Insomnia, you can see the operationName that it sends is has one less character…

{"query":"query Test123456789 {\n\tfake {\n\t\tid\n\t}\n}","operationName":"Test12345678","variables":{}}

I just ran into this. Upgrading to Insomnia 2023.1.0-beta.1 did not help. It may have been caused by “Copy as cURL”, the query worked fine before I did that. Notably, the operation name in the copied curl was truncated; I had query productBySku in my query and the operation name in the curl command ended up being productByS, and the resulting error in insomnia was Unknown operation named \"productByS\" . I did this in version 2022.7.5.

Hopefully that info is helpful in some way. I did fix things by manually recreating the query, then everything worked. And in beta1, when I copy as curl the operation is no longer truncated.