- From: Salvador de la Puente González <notifications@github.com>
- Date: Fri, 19 Feb 2016 12:28:49 -0800
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
Received on Friday, 19 February 2016 20:29:19 UTC
@mkruisselbrink you're right. Perhaps the solution of cancelling the `respondWith()` by using a special response could do the trick if we block threads at `respondWith()` call: ```js // handler 1: // 1. Gets the lock event.respondWith(new Promise(resolve => { // 3. After 1s, cancel the respond and release the lock. setTimeout(() => { resolve(event.cancelRespond()); }, 1000); })); // handler 2 // 2. Blocks and enqueue itself. // 4. After 1s, unblocks and get the lock. event.respondWith(new Promise(resolve => { // 5. After 2s, it responds with \0/ making other enqueued handlers to throw. setTimeout(() => { resolve(new Response("\0/")); }, 2000); })); ``` When respond's promise is resolved with a non `cancelRespond()` result, all other enqueued `respondWith()` throw: ```js Uncaught InvalidStateError: Failed to execute 'respondWith' on 'FetchEvent': The fetch event has already been responded to. ``` --- Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/836#issuecomment-186393274
Received on Friday, 19 February 2016 20:29:19 UTC