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" } } ] }
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
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 27
- Comments: 59 (2 by maintainers)
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.@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?Still reproduces on 2023.2.0
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: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.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’
And the issue is still there
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:
,"operationName":"Operations"
from the end of the queryThis 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.
@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 withunknown 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.
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:
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 theoperationName
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.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.
+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 🤷.
The error is still happening on 2023.2.2 😕
I got the same error today after updating Insomnia to the latest version!
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
Looking in the Timeline on Insomnia, you can see the
operationName
that it sends is has one less character…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 beingproductByS
, and the resulting error in insomnia wasUnknown 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.