Persisted queries not compatible with Relay

[DavidErben]

Screenshot

Configuration:

function subscribeFn(
  operation: RequestParameters,
  variables: Variables
): Observable<any> {
  return Observable.create((sink) => {
    console.log(operation);
    return subscriptionsClient.subscribe(
      {
        query: "",
        variables,
        extensions: {
          persistedQuery: operation.id,
        },
      },
      sink
    );
  });
}

Expected Behaviour

Library is compatible with Relay which requires to set an "id" property in the request parameters (and "query" probably to null).

Actual Behaviour

Relay throws an error because the "id" property is missing and no valid query has been specified. When Relay is configured to use persisted queries, the "operation.text" property is automatically set to null and only the "id" is provided. The "RequestParams" interface does not allow an "id" property and also query cannot be set to null.

https://relay.dev/docs/guides/persisted-queries/

Therefore persisted queries is currently not usable with this library. For fetching I am able to get it working by writing my own fetch function:

const response: Response = await fetch(
    `${process.env.REACT_APP_CORE_API_BASEURL}/graphql`,
    {
      method: "POST",
      headers: {
        Accept: "application/json",
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        id: operation.id,
        variables,
      }),
    }
  );

Is there any way to get it working with Relay? On my GraphQL server I can make a custom middleware to get the ID out of the extensions, but as long as Relay is throwing an error I can't get it to work at all. Thank you!

[enisdenjo]

The query field is required to be coherent with the GraphQL over HTTP spec.

What you should do is set an empty string to the query parameter and provide the persisted query ID within the extensions (exactly like you already do). The network layer is separate from Relay, it does not care about how you structure your request.

I reckon the error you're getting is originating from the servers response, not the request. You can confirm that by hooking up on the sink.error or sink.next and checking the errors field.

[DavidErben]

Thank you for your quick reply. It was indeed a server error. Some validation middleware executed before my custom middleware and aborted the request. I have now implemented a workaround to send a very short "fake" query text to please the validation middleware, then my custom middleware is executed and can pull the correct query ID from the extensions object.