v3.7.16

Patch Changes

• #10806 cb1540504 Thanks @phryneas! - Fix a bug in PersistedQueryLink that would cause it to permanently skip persisted queries after a 400 or 500 status code.

• #10807 b32369592 Thanks @phryneas! - PersistedQueryLink will now also check for error codes in extensions.

• #10982 b9be7a814 Thanks @sdeleur-sc! - Update relayStylePagination to avoid populating startCursor when only a single cursor is present under the edges field. Use that cursor only as the endCursor.

• #10962 772cfa3cb Thanks @jerelmiller! - Remove useGETForQueries option in BatchHttpLink.Options type since it is not supported.

Potentially breaking change in PersistedQueryLink

Previously, if the PersistedQueryLink encountered a single 400 or 500 error, it would stop sending any persisted queries in the future. This allowed you to use the link even if a server had no support for persisted queries.

We have decided to change this behavior, so now the PersistedQueryLink will only stop trying to send query hashes if the server responds with a PERSISTED_QUERY_NOT_SUPPORTED error code as it was unclear whether a 400 or 500 status code was in fact because the server did not support persisted queries.

If you relied on the previous behaviour, maybe because you were communicating with a server that might or might not support persisted queries, but would return with a different kind of error, you can use the disable option callback to override this behavior like this:

createPersistedQueryLink({
  // ... other options ...
  disable({ operation }){
    const { response } = operation.getContext();
    return (
      response &&
      response.status &&
      (response.status === 400 || response.status === 500)
    );
  }
})

Alternatively, consider removing the link entirely when your server does not support persisted queries.

New Contributors

• @sdeleur-sc made their first contribution in #10982