Graphql error - Unknown operation named \"Operations\"

[diogoX451]

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" } } ] }

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?

• I have searched the issue tracker for this problem.

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

[janmonterrubio]

This feels like a problem with your resource and not Insomnia, try using the StarWars API (free) https://studio.apollographql.com/public/star-wars-swapi/home?variant=current and hitting the example query. That will confirm whether its Insomnia, or the book.api

[scottBowles]

I just ran into this issue too and the StarWars API didn't work at first either. Using the StarWars API it was clearly able to pull in the schema, but when posting to the endpoint it gave a 500 and a similar response to @diogoX451. This was even worse than my localhost api, which was giving the weird "Unknown operation named \"Operations\" response but a 200.

I was eventually able to get the StarWars API to work after playing around with the query name, deleting a needing close parens, then adding the close parens back. After this is mysteriously worked. I was think able to get my local one to work after some similar finagling.

Now, if I have a trivial query like query Add {add(a: 1, b: 2)}, it works. But if I change the query name, it stops working, saying "message": "Unknown operation named \"Add\"" (even though at this point my operation name is Ad). If I remove the close parens, run the query, then add the close parens back and run the query again, it will then work with the new query name. When changing the name to a third thing, it doesn't reliably give either the original or the last working query name in the error message, so I am at a loss as to how that is working.

[filfreire]

Hi @diogoX451 and @scottBowles - it might be the case that when you first bumped into this issue you were using one of Insomnia's recent versions that had the unknown operation named problem.

I would recommend in this case that you upgrade to the latest Insomnia version, perhaps the beta release, try recreate a new graphql request and see if you can still reproduce the problem.

[diogoX451]

Using the beta version, the same error as always occurs, it would be the way I am performing the query differently or something from insonmia

[HectorOrdonezC]

Having the same issue as @diogoX451

[diogoX451]

I used postman, and all queries work perfectly, I thought it was something related to my request, but apparently not

[HectorOrdonezC]

Same, with Postman, worked. Even the Documentation fetch is better in Insomnia.

[mislav]

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

[diogoX451]

This "Operations" function that is disturbing the question of making the request, I see the advantage of insomnia that brings the documentation of the queries and mutations... But if it continues like this, I can't advance in the queries.

[w33ble]

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.

[adamredwoods]

+1 We had this same issue. Upgraded from Apollo 2->3 is when it started to occur.

[colinshum]

@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?

[mislav]

@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.

[philwhln]

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":{}}

[philwhln]

We've confirmed that this bug does not exist in version 2022.6.0

[philwhln]

Clicking here before "Send" resolves the issue...

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.

[narration-sd]

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

[glenntippett]

Clicking here before "Send" resolves the issue...

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

[MrOggy85]

I got the same error when I copy pasted the JSON directly from VSCode into Insomnia. I did not include query q { ... }, just the raw query like this { NAME_OF_QUERY() { ... } }

I got a workaround by prepending query q and hit "Send". Then I can remove query q and it is still working. Cheers! Hope it helps. Thanks for a nice piece of software btw 🍻

[w33ble]

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:

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.

[fabriciosautner]

This update that forces using Operations is very bad.

I really like insomnia, but that way I will have to turn to other software.

[narration-sd]

Sorry, the following is wrong, as marked: see next message. I hadn't checked far enough.

NO:

---

Interestingly, on 2022.7.5, up-to-date Windows 10, I'm not seeming to see this problem.

A named query works; if I alter the name, it alters in that UX visual also, and I don't have to touch it for things to work.

What may be different is that I'm using the no-install 'portable' version of Insomnia, though it's on the SSD of the laptop -- have any of you tried this?

---

YES

Really, though, this bug seriously needs to get fixed. There was another I ran into recently; can't remember, but it feels like development is getting looser, and Insomnia deserves better, no?

[narration-sd]

Well, spoke too soon. The bug is indeed there. Underlining the last statement.

I'll leave the above and apologize here, for anyone following just by email.

[jeblister]

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

[julesgilson]

I don't seem to recall having this issue until the last few months. Can't say I noticed the operations selector before either. In my case I think it is because I often duplicate an existing request, then edit it and Insomnia does not update (or remove if no named operations) the operation name.

Selecting the operation from the dropdown does remove the operation name from the request, but does not clear the operations drop-down.

Is Insomnia losing support? It would be a great shame as I prefer it a great deal over Postman or any other solution.

[medemi68]

I just encountered the same error today. Kind of a weird error and Insomnia is not the first thing I looked for i'll admit when I got it. I wonder if anyone at Insomnia has seen this?

[deadlyjack]

Disable automatic fetch. It'll will solve the issue.

[julesgilson]

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.

[deadlyjack]

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.

You're right. But for now it allows to make request and overcome the error.

[c10b10]

This is happening for me as well in:

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

[ChristianSch]

@filfreire you seem to have a lot of contributions this year. Can you relay this to the person that can resolve this? This bug is open for almost half a year now. Thanks 🙏

[orbziiharry]

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.

[paulvonber]

And the issue is still there

[k3karthic]

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 🤷.

[prosenjitjoy]

+1
And the issue is still there

[CostGranda]

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
		
	}
}

[kobenguyent]

I think it's not an issue anymore

[donni106]

Working for me as well today. Wow, yesterday it was still not working!

[jiri-muller]

I faced the issue after doing this steps:

1. I duplicated existing GQL request and moved it to new folder
2. I removed mutation that was in the request and replaced it with new query without name
3. Issue occurred
4. I tried naming query - Error message changed
5. I removed some empty lines bellow query
6. Everything works now 🤷

Version: Insomnia 2023.2.0
Build date: 4/26/2023
OS: Linux x64 6.2.0-35-generic
Electron: 22.0.0
Node: 16.17.1
V8: 10.8.168.20-electron.0
Architecture: x64

[jeor0980]

Having the same issue on MacOS

Version: Insomnia 8.3.0
Build date: 10/13/2023
OS: Darwin arm64 22.6.0
Electron: 25.8.1
Node: 18.15.0
Node ABI: 116
V8: 11.4.183.29-electron.0
Architecture: arm64

[elsurudo]

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.

[MAMahdhaoui]

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

[BenMorel]

Still having the same issue with Insomnia 8.4.5 on Ubuntu.

[sx328]

still not fixed 8.4.5 macOS apple silicon

[cwalworth]

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.

[narration-sd]

@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.

[cwalworth]

@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!

[narration-sd]

Addendum to the last comment, so it will be highly visible.

You do NOT have to sign up for an Insomnia account to use this latest version.

There is a tiny button at lower left on the big sign-in box, labeled with ScratchPad.
It doesn't look like a button, but does work.

Otherwise, you will run into one of the most arcane and dangerous-looking sign-up pages I think I've seen.
You'll be asked for a Google signin, even if you specify e-mail signin. It seemed to be legitimate, but I gave it a junk account just in case.

You'll be asked for some unrecognizable 'passphrase' business as well. With all kinds of caveats against their liability.
All this even though you've refused the push for paid account which cones, and denied you want to use any of their cloud.

Once I realized about the tiny button, I completely deleted this account.

It is also not helping their case to have developers presenting a hacker appearance, what childishness, complete with 'Chinese' puzzle code. Nor to have the months and months of delay fixing this current problem, if it is fixed. The code change looks like it might do this.

Insomnia has been a very good tool, put togeher by well-meaning persons. I think an adult will have to look at their current presentation, if they hope it will lead to subscriptions as a business. That's the best thought I can offer.

[narration-sd]

@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 🌲

[yesthesoup]

Running into this as well:

Version: Insomnia 8.5.1
Build date: 12/21/2023
OS: Darwin arm64 22.6.0
Electron: 28.0.0
Node: 18.18.2
Node ABI: 119
V8: 12.0.267.8-electron.0
Architecture: arm64

cwalworth's workaround worked for me thank you

[robross0606]

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.

[narration-sd]

Looks like they think they fixed it, back in October last year: #6733

I wonder about communications -- perhaps you might raise a fresh bug and link to here, as they're probably not seeing any comments since closing it.

I don't have much need these days, but when I do, I'm trying out the fork Insomnium, brought to attention here: #5752 (comment)

[tbutzzz]

Just ran into this as well...the kind suggestion of switching to json then deleting the operation worked nicely for me though, thank you