Client is sending null in the query

[FahdW]

My query payload which contains the file portion of the mutation is now sending null when i send the payload to my backend.

      file: acceptedFiles[0],
      type: 'OTHER',
    };
    const documents = [file];

 uploadOrderDocument({
      orderId,
      documents: [documents],
    }).then(res => console.log(res))
      .catch(err => console.log(err));

[jaydenseric]

Are you using the latest versions of apollo-upload-client, and apollo-upload-server? They are using a newer version of the GraphQL multipart request spec.

[levvsha]

@jaydenseric Is it possible to specify the value that will replace files instead of null? Our backend is built in such a way that it produces an error if it gets an array with null values.

[crirus]

I'm on the same boat with this, I can even accept a 'true', '1', etc, or the actual file names instead null

[jaydenseric]

I'm not sure what you guys are explaining, because upollo-upload-server processes the request for you so your resolvers don't see any null values; they get Upload scalars with stream, filename, etc.

[crirus]

I am not using apolo-upload-server, just the client and my implementation is standard graphql that rejects queries with fields set to null :)

[jaydenseric]

@crirus You need a server implementation for the GraphQL multipart request spec running before your GraphQL server or nothing will work properly.

[crirus]

@jaydenseric I know, we already handle your operations and maps POST keys, but inside the input query, all fields about files are set to null, hence the query is invalidated before we get control of execution in resolvers.

We could convert that input query to change the nulls, but it could be more elegant if your client send some acceptable, useful values instead.

From my point of view, you could put there an array with file names

Regards
Cristian

[jaydenseric]

@FahdW We can reopen this if you decide to answer my earlier question about what versions you are using and clarify the problem. I can't understand what your issue with apollo-upload-client actually is; the code excerpt does not have any context and does not look like a typical use of the Apollo Client API. It's also confusing what you mean by the client sending null in place of the files, since in a way that is what is meant to happen.

@crirus It seems you are trying to build a custom server implementation of the spec and are finding it challenging. The right place to discuss that is the #uploads chanel of the Apollo Slack where I would be happy to help.

[crirus]

it's not a custom built, it's using facebook graphql protocol. Simply, if yous end a field with null, it's not accepted. Even 0 is fine.

[jaydenseric]

@crirus see jaydenseric/graphql-multipart-request-spec#4 (comment).

I think you are confused about how this ecosystem fits together.

[crirus]

I am not, neither you are: basically you use null, graphql is not accepting it. I don't know why is a problem (if is a problem) to put anything there but null. :)

[jaydenseric]

Your GraphQL server should never receive a null value, because you should have middleware that decodes the multipart request according to the spec, and creates the standard input the GraphQL server expects to consume later in the middleware chain.

I'm guessing that because you have not setup apollo-upload-server as per the instructions, you must have a non-Node.js environment. There are other server implementations for PHP and Ruby you can try.

[crirus]

I know, exactly this is happening, we have a middleware to deal with this special POST format, we also replace those nulls, but we could avoid looping through all the queries, if client would send something else.

[FahdW]

@jaydenseric you can close this issue I managed to fix my issue.