Workers returning cache hit for 500 response without cache headers
I have a remix application deployed to cloudflare pages. We recently had a scenario where some unexpected load was generated against our API which caused an outage. The specifics of this are still being investigated, but as this happened we found that the remix application took longer to recover than the API itself. From what we can see the 500 response from the worker as a result of the api outage had been cached and as such the cached response continued to be returned after the API recovered.
I have attached a screenshot of the response. We cannot see any specific details of the response that would indicate that it should be cached like a cache-control or expires header. We currently have a very rudimentary implementation of the cache api within our worker function which we suspect needs to be updated to avoid this. However I have been unable to find any documentation explaining the condition which is causing it to be cached making it difficult to know what changes exactly are required. Ideally we would just like our cache implementation to match the behaviour of cloudflare when not using workers. I'm not sure how practical that is though. I have attached our worker entry point for reference as well.
I have attached a screenshot of the response. We cannot see any specific details of the response that would indicate that it should be cached like a cache-control or expires header. We currently have a very rudimentary implementation of the cache api within our worker function which we suspect needs to be updated to avoid this. However I have been unable to find any documentation explaining the condition which is causing it to be cached making it difficult to know what changes exactly are required. Ideally we would just like our cache implementation to match the behaviour of cloudflare when not using workers. I'm not sure how practical that is though. I have attached our worker entry point for reference as well.
