error navigating to route that loads data about remix HOT 14 CLOSED

Thanks @cdock1029, we're removing make-fetch-happen right away, will close this issue as soon as the new version is pushed.

from remix.

If you want to get unblocked, don't return the fetch directly, unwrap it and send your own:

const { json } = require("@remix-run/react");

module.exports = async () => {
  let res = await fetch(url);
  let body = await res.json();
  return json(body)
}

https://remix.run/dashboard/docs/loader#json-helper

from remix.

It is intermittent though, but seems to happen when clicking around quickly. I also checked at it is not just a development issue, it also happens on the production build. BTW it is nice that the prod build is just like development, this will save a lot of head scratching in the future.

from remix.

Every time the error occurs, it's a 304 and the "request has no response data available".

Some combination of clearing cache and reloading server avoids the error for a while. Maybe it's a chrome issue.. not sure.

from remix.

Hey @cdock1029!

Can you post your loader code?

from remix.

loaders/routes/team.ts

module.exports = async () => {
  return fetch(`https://api.github.com/orgs/reacttraining/members`);
};

from remix.

Hard to reproduce.. not seeing it for a while now, but previously was getting it every request. Would have ignored if other use didn't post exact same error.

Not fully aware of http / browser interaction.. does 304 mean browser should have the data? I logged the loader function and it had data from fetch and returned it.

Always it was an empty response when it failed (thus the JSON message I assume)

from remix.

Im seeing this too. It seems to happen when _remix/data responds with a 304 and theres no json body.

from remix.

I wonder if this can be related to blindly passing along response headers from github to the client. For instance if a 304 is returned from github this could be out of sync if the response caches are origin specific.

from remix.

FWIW, changing the loader to pass through only relevant headers and not mirror the response code seems to solve the issue. Maybe returning fetch(...) directly is just a little too cute.

module.exports = async ({ params }) => {
  const res = await fetch(`https://api.github.com/users/${params.member}`);
  return new Response(res.body, {
    status: 200,
    statusText: 'OK',
    headers: {
      'Content-Type': res.headers.get('content-type'),
      'Cache-Control': res.headers.get('cache-control')
    }
  })
};

from remix.

I'm kinda of wondering how the server's cache could ever be in sync with the browser's cache to make 304's work?

If github returns not modified, and our server passes that back to browser, what if the browser doesn't have the data? Also, the browser didn't pass any E-tag to github... our server did right?

I think we'd have to somehow sync the "request" passed from browser into the fetch on the server for the caching to be consistent...

This is hard to reproduce because the fetch to github on the server doesn't often return a 304 it seems. But i did get it to reproduce if you load the data route first, then go back to "Home". Then clear the browser cache, and fetch the data route again.

If the status is a 304 at that point, the error will trigger because I think the browser doesn't have the data referred to by the E-tag sent by the server.

Just thinking out loud, I'm certainly not very well versed in this stuff, so could be off base.

npm/make-fetch-happen#28

This might be relevant, but in our case we would seem to want this behavior if we wanted to pull from the browser cache, though as described this doesn't seem to work now

edit:

Something like this maybe.. now I see 304's on client side.

module.exports = async ({ context: { req } }: any) => {
  return fetch('https://api.github.com/orgs/reacttraining/members', {
    headers: {
      'If-None-Match': req.get('If-None-Match'),
    },
  })
}

from remix.

I'm getting the same issue, posted in Discord and here's a short video. For me it's happening pretty consistently when hitting the back button.

https://cln.sh/mJds3Y

from remix.

Since make-fetch-happen uses a server-side cache, if If-None-Match isn't provided in the the fetch initialization, fetch will use the server cache to define this itself.

We can see how this gets out of sync. Populate the server cache by making some requests in the browser. Then open an incognito window. This client will now not be passing any e-tag because it has no data in its cache. But when the loader makes a fetch call, it will look in its own cache and forward an e-tag. If the external API returns 304, this response is then passed back to browser, telling it to redirect the to its cache which doesn't have the data.

from remix.

fixed in remix-run/remix#0.6.1

from remix.