Closed
Bug 1244714
Opened 9 years ago
Closed 9 years ago
Surface error when push server down?
Categories
(Core :: DOM: Push Subscriptions, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jujjyl, Unassigned)
Details
(Whiteboard: dom-triaged)
STR:
1. Navigate to https://serviceworke.rs/push-rich_demo.html
2. Accept the push notification send dialog that shows up.
3. Click on "Try to conquer Italy"
4. Wait for a push notification to arrive
Expected: A push notification "Alea iacta est." should arrive in 5 seconds. I am not sure about the exact state of Firefox push notification support, but given that Firefox does post the security dialog about allowing push dialogs at step 2, I'm expecting that the feature should be functional?
Observed: The push notification does not arrive either in FF stable 43.0.4, FF stable 44.0, FF Nightly 47.0a1 (2016-01-31) or FF Nightly 47.0a1 (2016-02-01). The push notification does arrive when using current Chrome 48 (indicating the test is likely not at least completely broken).
Reporter | ||
Comment 1•9 years ago
|
||
Not sure if this is a Service Workers or Push Notification specific issue, so defaulting to the more specific label.
Component: DOM: Service Workers → DOM: Push Notifications
Comment 2•9 years ago
|
||
Jukka, have you used the same profile with multiple versions of Firefox? There is a bug with the Cache schema changing and we store the SW script there.
It works for me in nightly, FWIW.
Flags: needinfo?(jujjyl)
Whiteboard: dom-noted
Comment 3•9 years ago
|
||
We had a push server outage over the weekend. I'm pretty sure that was the problem here. The site did not work for me early monday morning, but does now.
Jukka, can you try again?
Comment 4•9 years ago
|
||
The outage was from Sunday evening (2015-01-31, 5pm PST) to Monday morning (2015-02-01, 9:30am). That likely caused this issue, as well as bug 1244717.
Comment 5•9 years ago
|
||
(In reply to Andrew Overholt [:overholt] from comment #2)
> Jukka, have you used the same profile with multiple versions of Firefox?
> There is a bug with the Cache schema changing and we store the SW script
> there.
Bug 1242056 is the bug I was thinking of.
Reporter | ||
Comment 6•9 years ago
|
||
Andrew, there was no errors being reported, i.e. no TypeError, so assuming that was not the issue.
Tested again today and it works now, so comment 3 seems correct. Bug 1244717 as mentioned in comment 4 cannot be a cause for this bug, since the repro in bug 1244717 builds/expands on the repro in this bug.
Overall, when the server was out, this test effectively caused a silent failure. That does not sound good. What, if anything, can we do to improve the flow for such server outages? Can we report an error back in such cases?
Flags: needinfo?(jujjyl)
Comment 7•9 years ago
|
||
Kit, Martin, is it possible to bubble up an error when the server's down?
Flags: needinfo?(martin.thomson)
Flags: needinfo?(kcambridge)
Summary: Service Workers "Push Rich Demo" does not work. → Surface error when push server down?
Comment 8•9 years ago
|
||
Jukka, did you see an HTTP 500 error when you sent a POST to the endpoint URL? When I tried it out Monday morning (before we restarted the server), calling `pushManager.subscribe()` worked, but POSTing to the endpoint returned a 500. This can return other errors, too, like a 404 if the subscription has been removed.
The demo at https://github.com/mozilla/serviceworker-cookbook/blob/master/push-simple/server.js needs a `.catch()` to check for errors, too. I'll file an issue.
Flags: needinfo?(kcambridge)
Comment 9•9 years ago
|
||
index.js needs to catch and log errors too.
Andrew, In terms of reporting, this is difficult. Errors with the push service would have to be surfaced in the service worker (since errors can happen any time) but that creates some problems. If the push service is down, the most likely reason is that your machine has gone offline. Pinging every service worker for that very common scenario is going to make us quite sad, I think.
As Kit identified, if the push service is returning errors to the application server, then most of the work is being done. That leaves the user with no recourse, since the error indication is made to an entity that likely can't reach the user now that their primary communication channel is down, but I think that the alternative is worse.
If we had a reliable indication that the network was up (I think that Valentin or Daniel was working on this) and the push service was down, maybe we could surface something, but we'd still have to make the call about waking service workers.
Flags: needinfo?(martin.thomson)
Updated•9 years ago
|
Whiteboard: dom-noted → dom-triaged
Reporter | ||
Comment 11•9 years ago
|
||
It sounds odd that it would be possible to contact an external server to register a push notification to occur, but that a server outage can cause that push notification to not be received back? How can a server outage be "one-sided" (registering works, but receiving doesn't)? Doesn't registering a push notification require a live network connection?
I agree on the decision of making this a WONTFIX on the terms of that tracking would be too costly, as I don't know enough about the push arch at all to suggest otherwise.
Marked down https://bugzilla.mozilla.org/show_bug.cgi?id=1246615 regarding comment 2 (after the servers came up, I am now seeing that in effect), since that is a recurring theme that we keep running surprisingly often, and it would be good to patch that up somehow.
Flags: needinfo?(jujjyl)
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•