Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uploading image from AdminUI using apollo-upload-client returns INTERNAL_SERVER_ERROR, "message":"Missing multipart field ‘operations’ #2516

Closed
ra-external opened this issue Mar 13, 2020 · 5 comments

Comments

@ra-external
Copy link

ra-external commented Mar 13, 2020

I'm trying to upload an image (list Image) with the following GraphQL schema

  createImage(data: ImageCreateInput): Image

input ImageCreateInput {
file: Upload
}

from TinyMCE (as a custom field) inside the AdminUI. Following these instructions (https://stackoverflow.com/questions/60656730/how-can-one-upload-an-image-to-a-keystonejs-graphql-endpoint/60657015#60657015) I'm using Apollo-upload-client, which apparently is already installed in the AdminUI as the Apollo Client. Following the Apollo-upload-client docs (https://github.com/jaydenseric/apollo-upload-client#blob) I am uploading the blob from inside the TinyMCE images_upload_handler

```

const UPLOAD_MUTATION = gqlmutation upload($data: ImageCreateInput!) { createImage(data: $data) { id file { path filename } } } ;

images_upload_handler: function(blobInfo, success, failure) {

		const image = blobInfo.blob();
		try {
			log.debug('about to mutate');
			log.debug(client);
			client.mutate(
			{
			mutation: UPLOAD_MUTATION,
			variables: { data: { file: image } }
			}
			).then(result => {
			log.debug('result');
			log.debug(result);
			success(result);
			});
			} catch (e) {
			log.debug('error', e.toString());
		failure(e);
		}
}

however KeystoneJS logs the following error, complaining of `Missing multipart field 'operations'`.  

> {"level":50,"time":1584092923059,"pid":29020,"hostname":"somewhere.or.other","name":"graphql","message":"Missing multipart field ‘operations’ (https://github.com/jaydenseric/graphql-multipart-request-spec).","extensions":{"code":"INTERNAL_SERVER_ERROR"},"uid":"ck7q00y3x0000e4rjfevaapo3","stack":"<Original stack missing>\n    module.exports (node_modules/ensure-error/index.js:28:16)\n    _formatError (node_modules/@keystonejs/app-graphql/lib/apolloServer.js:97:44)\n    node_modules/apollo-server-errors/dist/index.js:167:34\n    Array.map (<anonymous>)\n    Object.formatApolloErrors (node_modules/apollo-server-errors/dist/index.js:165:27)\n    node_modules/apollo-server-express/dist/ApolloServer.js:47:39\n    runMicrotasks (<anonymous>)\n","name":"BadRequestError","v":1}
@ra-external
Copy link
Author

As a followup, it would seem that the client side is sending the correct information, and this is a server-side issue.


Summary
URL: http://localhost:4545/admin/api
Status: 400 Bad Request
Source: Network
Address: ::1:4545

Request
POST /admin/api HTTP/1.1
Cookie: keystone.sid=s%3A2OXYDUkDenT3i6yu3lVQpSafC3AQ_5vq.XiOyB1gahSc%2FFjaNq36dnEIL4Vk0VwR%2FBq6lY7NDLyk
Accept: */*
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryDjNz6A1qrij1s1Ye
Origin: http://localhost:4545
Content-Length: 10871
Accept-Language: en-us
Host: localhost:4545
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15
Referer: http://localhost:4545/admin/articles/5e6a119a07e2e826a71b0cf5
Accept-Encoding: gzip, deflate
Connection: keep-alive

Response
HTTP/1.1 400 Bad Request
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'
Content-Type: text/html; charset=utf-8
Date: Fri, 13 Mar 2020 13:18:09 GMT
Connection: keep-alive
Vary: Origin
Content-Length: 142
Access-Control-Allow-Origin: *
X-Keystone-App-Version: 1.0.0
X-Powered-By: Express

Request Data
MIME Type: multipart/form-data
Boundary: ----WebKitFormBoundaryDjNz6A1qrij1s1Ye
Request Data: 

------WebKitFormBoundaryDjNz6A1qrij1s1Ye
Content-Disposition: form-data; name="operations"

{"operationName":"upload","variables":{"data":{"file":null}},"query":"mutation upload($data: ImageCreateInput!) {\n  createImage(data: $data) {\n    id\n    file {\n      path\n      filename\n      __typename\n    }\n    __typename\n  }\n}\n"}
------WebKitFormBoundaryDjNz6A1qrij1s1Ye
Content-Disposition: form-data; name="map"

{"1":["variables.data.file"]}
------WebKitFormBoundaryDjNz6A1qrij1s1Ye
Content-Disposition: form-data; name="1"; filename="blip.jpg"
Content-Type: image/jpeg


------WebKitFormBoundaryDjNz6A1qrij1s1Ye--

@stale
Copy link

stale bot commented Jul 15, 2020

It looks like there hasn't been any activity here in over 6 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contribution. :)

@stale stale bot added the needs-review label Jul 15, 2020
@Echooff3
Copy link

I'm running into a similar issue using the S3FileAdapter. I followed the steps from the documentation on how to set it up. https://www.keystonejs.com/keystonejs/file-adapters/#s3fileadapter
I can verify that the operations section of the form-data does include the name="operations" section.

What was really odd that 2 days ago I was able to upload without any issues. I spun up a new keystone project and simply set up a list with a name and an image field and was seeing the same Missing multipart field 'operations' error.

Are there any tips on how to debug this? Any way to verify that the AWS S3 / Cloudfront config is correct?

@stale stale bot removed the needs-review label Jan 14, 2021
@Echooff3
Copy link

I ended up upgrading from Keystone v17.1.2 to v18.0.0 and the uploads started working again. If that happens to help anybody.

@bladey
Copy link
Contributor

bladey commented Apr 8, 2021

Keystone 5 has officially moved into active maintenance mode as we push towards the next major new version Keystone Next, you can find out more information about this transition here.

In an effort to sustain the project going forward, we're cleaning up and closing old issues such as this one. If you feel this issue is still relevant for Keystone Next, please let us know.

@bladey bladey closed this as completed Apr 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants