How to gracefully handle "operations form field could not be decoded

[amitavaghosh1]

What happened?

We have a mutation part in schema which looks like

type Mutation {
    submit(file: Upload!, accessToken: String): GenericResponse
}

and we try to upload a file like this:

curl http://localhost:9003/siic-gql-server/graph/plans/query \
-H 'Authorization: Basic SuperSecret' \
-F operations='{"query": "mutation submit($file: Upload!,$accessToken:String) { submit(file: $file, accessToken: $accessToken) { success }}", "variables": { "file": null, "accessToken":  "SomeToken"}}' \
-F map='{ "0": ["variables.file"] }' \
-F 0=@./a.txt -vvv

In our case the acessToken is quite long

And we keep getting:

{"errors":[{"message":"operations form field could not be decoded"}] }

Or the server

 2021/06/15 - 22:24:12 | 422 |    1.461997ms |             ::1 | POST     "/query"

What did you expect?

Not this to happen. Is there any limit on the size of the request body? and if yes can we increase it? or is this error generated from something else. I believe it's the size of the body.

Minimal graphql.schema and models to reproduce

versions

• gqlgen version? github.com/99designs/gqlgen v0.13.0
• go version? go version go1.15.2 darwin/amd64
• dep or go modules? go modules

[DenChenn]

I encountered the same problem...

[Niennienzz]

I am using Go v1.16 & gqlgen v0.14.0, and it works fine for me. Some suggestions:

• Make sure the operations field is a valid JSON in that string. In the posted example it is valid, however, make sure it is still the case when you have a longer token. (i.e. missing brackets, special characters etc.)
• This is not directly related to your problem, but consider sending the token in HTTP header/cookie as in the doc example.

[srinivasan1211]

facing the same issue, any solutions or workaround?

[amitavaghosh1]

I am not sure of this, but one thing I have noticed, while making use of this feature, you can upload an attachment, only if the total length of your query is less that a certain size.
I haven't looked into the actual cause, but when I was trying to upload an attachment, I also passed 12-13 other key value values. And it didn't work, when I reduced the number of k-v pairs, then it would upload the same file successfully.

We ended up ditching the upload thing, because we felt, since it was not a part of spec of the original graphql and given the nature of the problem, we used normal file upload. And that would return an id which would be sent as a part of the graphql mutation.

[TheBeachMaster]

I still can not figure out the solution to this problem, and @amitavaghosh1's solution may not work in my case, since my operation is a Signup - so a user's profile photo is required and a bunch of other fields.

// ...
	gqlSrv.AddTransport(transport.POST{})
	gqlSrv.AddTransport(transport.MultipartForm{
		MaxMemory:     32 * mb,
		MaxUploadSize: 50 * mb,
	})
//...

Request

curl --request POST \
  --url http://localhost:33200/service \
  --header 'Content-Type: multipart/form-data' \
  --form 'operations="{\"query\": \"mutation SignupUser($userInfo: SignupUserInput{ signupUser(input: $userInfo) { firstName, lastName } }\",\"variables\": {\"userInfo\": {\"password\": \"tested\",\"profilePhoto\": null,\"firstName\": \"Guy\",\"lastName\": \"Luemba\",\"phoneNumber\": \"+254720000000\"}}"' \
  --form 'map={ "0": ["variables.userInfo.profilePhoto"] }' \
  --form '0=@/Users/whoami/Desktop/Screenshot 2022-07-01 at 17.58.15.png'

Gqlgen version: github.com/99designs/gqlgen v0.17.10