Apollo-client: Cannot read response data in afterware

[pleunv]

Hi!

I've got a scenario where I want to have a look at the response data in the afterware (async cqrs - in case of an async command response I need to wait for a websocket confirmation event to come in before proceeding). However, since we're getting Response objects I need to resolve response.json() to get to the data. The problem here is that networkInterface.js also resolves the Response once all afterwares have been called:

return httpResponse.json().catch(function (e) {
  var httpError = new Error("Network request failed with status " + response.status + " - \"" + response.statusText + "\"");
  httpError.response = httpResponse;
  throw httpError;
});

Which leads to me getting a network request failure due to a TypeError: Already read exception since Response.body can only be read once.

Would a possible solution be to parse the response body before passing the response into the afterwares?

Intended outcome:

Ability to parse (or ideally receive) the response data in the afterware

Actual outcome:

Parsing is not possible since a response body can only be parsed once, which is normally happening in networkInterface.js. As a result apollo is throwing network request failures.

How to reproduce the issue:

Add an afterware that parses the body:

{
  applyAfterware: (res, next) => {
    res.response.json().then((json) => console.dir(json));
    next();
  }
}

[fc]

It looks like this could be temporarily solved using the batch network interface until a fix is in regular network interface. Someone correct me if I'm wrong on this... but take a look:

See the batch network interface here (batchedNetworkInterface.ts) where it checks httpResponse.ok instead of doing a try-catch like it does with the other one:
https://github.com/apollographql/apollo-client/blob/master/src/transport/batchedNetworkInterface.ts#L86

Where as here it does resolve the response (networkInterface.ts):
https://github.com/apollographql/apollo-client/blob/master/src/transport/networkInterface.ts#L203

Check out the example on the batch example network interface here (note batching only works on servers that support it):
http://dev.apollodata.com/core/network.html#BatchingExample

[cesarsolorzano]

I think it's necessary to remove httpResponse.ok from batchedNetworkInterface and make it similar to the networkInterface in order to avoid #1238.

Perhaps, the solution here is to clone the response object instead of sending it back in httpError.response = httpResponse

[fc]

It looks like this could be resolved by this PR #1425

[helfer]

@pleunv this is not really a bug imho. You can clone the response and then parse it. However we're woking on a new network interface that pre-parses the response to make this easier, so it shouldn't be a problem any more soon.