When working with the
fetch event inside the Workers runtime, it helps to have a good idea of its lifecycle.
The FetchEvent lifecycle starts when Cloudflare’s edge network receives a request whose URL matches both a zone and a route for a Workers function; this causes the Workers runtime to trigger a
fetch event and creates a FetchEvent Object to pass to the first event handler in the Workers function registered for
'fetch'. Then the event handler can use any of the following to control what happens next:
Intercepts the request and allows users to send a custom response.
fetch event handler does not call
respondWith(), the runtime delivers the event to the next registered
fetch event handler. If no event handler calls
respondWith(), the runtime proxies the request to the origin. Note: If no origin is setup (always true for workers.dev sites), then you must have a
respondWith() called for a valid response.
Extends the lifetime of the event using a
Promise passed into the function. Use this method to notify the runtime to wait for tasks, such as streaming and caching, that run longer than the usual time it takes to send a response. This is good for handling logging and analytics to third-party services, where you don’t want to block the
passThroughOnException() causes the Workers runtime to yield control to the origin server.