I’m curious how you are observing the exception – e.g. in the console in the preview service, or reported via response header/body in production? It’s uncommon for an exception to truly have no stack trace (i.e., no
stack property), and it would help me understand the issue if I knew the context in which the exception was observed.
Both Request and Response bodies become disturbed when they are:
- read from. This can happen explicitly by calling
response.body.getReader().read(), or implicitly through the
- canceled. This can only happen by calling
Request bodies additionally become disturbed when one request is used to construct a new Request without replacing its body (e.g.,
new Request(oldRequest)), and when they are passed to
Response bodies additionally become disturbed when they are sent to the eyball (via
event.respondWith()) or to cache (via
Since explicit reading and cancelation would presumably be obvious in your script, I’d focus on searching for code paths where one of the latter cases can occur twice. For instance,
cache.put()ing a Response object, then using it as an eyeball response, or conditionally reconstructing a Request, then using it in a
Another thing to consider is that some code paths might work with null bodies but might throw when there is a body – e.g., GET versus POST requests, or 204 status versus 200 status responses.