Re: [push-api] Multiple consecutive messages (#168)

What you describe as "next stage of the pipeline" means "has been received by the UA". In context of the two-device example where collapsing cannot be used, this means that the case in which this would happen is:

1. **AS**: Sends "you've got mail" announcement to UA1 and UA2.
2. **UA1**: Announcement received, event queued up and dispatched.
3. **UA1**: Announcement acknowledged by user, informs app server.
4. **UA2**: _[comes online]_ Announcement received, event queued up, _not_ dispatched yet.
5. **AS**: Sends "ignore that message" cancelation to UA2.
6. **UA2**: Cancelation received, event queued up, dispatches both events in order.

The race happens between step {4, 5} and 6 - the order of 4 and 5 can be reversed when we account for the latency between the AS, the PS and the UA.


The synchronous part of invoking the `push` event is run-to-completion, any other operation the developer would do is very likely to be asynchronous. Firing subsequent events happens sequentially, they are not blocked on the previous one _finishing_ (accounting for `waitUntil`) - this is what I meant by running in parallel.

If we assume all events have been added to the task queue before any of the events run, you're proposing to add a mechanism to peek into the task queue and grant access to any queued `push` events, including their data. The mechanism would only provide value during the synchronous part of the event, as the queue would have been flushed by the time any Promise settles.

This introduces a lot of complexity, and introduces a concept (peeking into the task queue) that, to my knowledge, does not exist in the Web platform yet. It also makes the assumption that the UA is able to queue up all pending events before tasks in the task queue are being executed - this may not always be the case.

I'm not at all convinced that the added complexity is worth it. The chance of this happening, when message collapsing is appropriately used (not informing the UA in the first place is highly preferred), is very theoretical. Have you seen this in practice?

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/168#issuecomment-152912262