This bug needs more details, but I think M51 made some changes to push subscriptions so it might be an expected change. See  issue 583753 .

promise is always pending never get a response

Deleted: Screen Shot 2016-06-30 at 11.15.37 PM.png 52.0 KB

	Screen Shot 2016-06-30 at 11.15.37 PM.png 52.0 KB View Download

Are you trying this in Incognito by any chance? It should auto-settle after a few seconds in that case.

One thing to try is to visit chrome://gcm-internals in another tab before trying to register, click the "Start Recording" button(!), and then follow the regular subscription flow.

That page should give you further diagnostics to see what's going on.

Hello,

I'm experiencing the same error, and I've attached what chrome://gcm-internals shows as an image.

Deleted: gcminternalslog.png 358 KB

	gcminternalslog.png 358 KB View Download

Meant to add on to previous comment:

I'm not using Chrome's Incognito mode, and the promise to PushManager.subscribe() also similarly does not return. In the past (just this morning), the same code has been working. In the past, I think I've been able to create a new profile to get past this error, but I'm hoping for another workaround!

Can you tell me what do you mean by new profile ??

I've attached my full chrome://gcm-internals page as a PDF. Hopefully this is more helpful. I have a large number of Registered App Ids due to some automated tests to test subscribing and unsubscribing.

I wonder if removing some of the Registered App Ids might solve the issue? I ran the tests for the first time last night, and then this issue started cropping up. Previously, the issue also appeared after running the tests many times in succession, though it took a week for the issue to appear. Any way to remove the Registered App Ids?

@richi3, by creating a new profile, I followed these steps (https://support.google.com/chrome/answer/2364824?hl=en).

Deleted: GcmInternalsLog.pdf 801 KB

GcmInternalsLog.pdf 801 KB Download

Creating a new profile worked thanks. But chrome needs to fix that issue and come up with a better solution.  

By any chance richi3, do you also have a large number of Registered App Ids like I do (see GcmInternalsLog.pdf on #8)?

I got none as I was developing a service worker so kept registering and removing for testing purpose and all of a sudden it stopped working on my chrome Firefox still works fine. 

Did you find a solution for this? I have the same issue.

Same problem here, chrome v53,
pushManager.subscribe doesn't return the promise

Logging into chrome using different Gmail Id works. But I understand that's not a proper solution as you cannot ask the people who wants to subscribe to change their Gmail account. It seems the chrome devs aren't bothered to do anything. 

An easier solution than removing your Google profile (since that means removing your extensions), is to delete the "GCM Store" folder. kovalevski found the folder here (https://github.com/OneSignal/OneSignal-Website-SDK/issues/94#issuecomment-250103605):

Remove or move: /Users/[user-name]/Library/Application Support/Google/Chrome/Default/GCM Store

Just wanted to say this issue is still affecting some users on Chrome 53.0.2785.143 (latest). We're continuing to hear from people where the subscription hangs from pushManager.subscribe() does not resolve or reject.

I am experiencing the same problem on my end as well.

The pushManager.subscribe() does not return anything and I am unable to save the playerid into my application's database.

It only happens on Chrome-Mac.

I am seeing this issue at many of our users. It also happens in Chrome on Windows.

Something interesting is that, for the first time I encountered this error intermittently. Normally the moment I encounter this error, it affects subscription on all sites and I just have to remove my GCM store folder. But this time I was able to  try subscribing again on the same site, and it worked!

I was running automated tests that would subscribe relatively quickly (maybe 3 / second), so maybe there was a rate limit? I wasn't able to capture what the issue was in chrome://gcm-internals.

Updated command to remove old GCM Store folder: 

mv ~/Library/Application\ Support/Google/Chrome/Default/GCM\ Store ~/Library/Application\ Support/Google/Chrome/Default/GCM\ Store\ Old

We are seeing this issue on Chrome/Windows. Deleting GCM store didn't fix the issue for us.

We're now seeing this bug (or behaviour that matches exactly what we would predict if this bug occurred) on sites for which we do web push. We don't (currently) use subscription restrictions (as per https://bugs.chromium.org/p/chromium/issues/detail?id=583753). The bug is visible in the latest stable Chrome. It is intermittent in that it doesn't affect all users - once it has affected a user for a given site, it appears to stay that way.

Additional: one of our internal users encountered this. Removing the GCM Store folder did *not* resolve the issue.

Hey Benl, maybe there were multiple GCM store folders under different profiles folders (folders called something else other than default)? Have you tried removing those? Just a guess, I'm not sure what the real solution is, it's just removing the GCM store folders previously worked for me.

Good point, but what we're really looking for is a way to fix this in code - can't ask end-users to remove folders!

Is there any way to raise the priority of this issue, or find out what extra feedback the Chrome team needs? We are now seeing this in the wild (added code that detects a never-resolving Promise and times out), and it's leading to failed subscriptions for customers.

John, could you share an update?

Something that may help; I've just been using Saucelabs to test some code with older versions on Chrome, and got a "never-resolving" subscribe() timeout on Chrome 45. The timeout is set to 20 seconds. A subsequent test on a different website successfully subscribed.

It's not possible to know if the timed-out subscribe() call would have resolved; I typically do not see any delays in subscribe() on Saucelabs browsers, certainly nothing more than a few hundred mS at most.

We are experiencing a problem similar to this on many of our users. 
chrome://gcm-internals/ says that GCM Client State is UNINITIALIZED. Removing GCM Store folder resolved this issue.

Deleted: Win_10_pro_gcm_uninitialized.jpg 58.1 KB

	Win_10_pro_gcm_uninitialized.jpg 58.1 KB View Download

Hi folks, I've been looking into these errors with the GCM team.

Firstly, I suspect the hanging promises are caused by automatic retries: both subscribe() and unsubscribe() will automatically retry certain kinds of failed request to GCM servers for around 10 minutes (with exponential backoff) before resolving/rejecting the promise. I'd be very interested in feedback from web developers on whether this is useful, or if it'd be better to just reject the promise after the first failure and let websites worry about retrying network errors?

Jason (OneSignal): thanks for the chrome-internals PDF in comment 8, that was very helpful. In your case, you had too many registrations (presumably due to the automated tests) - there's currently a limit of 1000 registrations per device (on desktop this corresponds to a Chrome profile). And it's one of the errors that we perform automatic retries for (my patch below stops retrying this error). Deleting the GCM Store folder works because it resets your device ID; presumably your automated tests could also unregister the registrations to avoid getting into this state.

Ben & everyone else: if possible, please could you go to chrome://gcm-internals and Start Recording before reproducing this bug. Then list the following information after reproducing the bug:
- GCM Client State
- Connection State
- all the entries in the Details column of the Registration Log (e.g. UNKNOWN_ERROR, or REACHED_MAX_RETRIES) for Registration response
received events.

That'll let us see if you're experiencing the same root cause, or a different type of registration error (that also triggers automatic retries). I understand that it can be hard to ask end users to provide this information, so we're also going to closely analyse our UMA metrics to see if there are any unexpected sources of registration failures.

I've also written a patch to make it clearer (both in chrome://gcm-internals and in our UMA metrics) what the errors previously listed as UNKNOWN_ERROR are caused by - https://codereview.chromium.org/2434243002 - and to stop automatic retries for the QUOTA_EXCEEDED and TOO_MANY_REGISTRATIONS cases.

Other information that would be useful (and *doesn't* require having pressed Start Recording) is to go to chrome://histograms after the problem occurs (but before restarting the browser) and attach a .txt file with a copy of all the entries starting with "GCM." (especially GCM.RegistrationRequestStatus, GCM.CheckinRequestStatus, GCM.LoadStatus, GCM.Database.Open, and GCM.ConnectionFailureErrorCode).

Thanks for the update!

Feedback from me: if Chrome rejects the promise (in the event of a timeout), unless the error response is clearly documented, our code can't really do anything to fix the issue - we can't tell whether the error is one that allows a retry or not. Even if we can retry, that's certainly less than ideal - we will already have prompted the end-user to subscribe, and adding code to handle retrying of the subscription adds yet more complexity.

It'd be preferable if Chrome generated the subscription and resolved the promise, even if it then has to wait to communicate with GCM. If the communication fails, there's always the pushsubscriptionchange event to advise the service worker that the subscription is dead. Of course, this would also require GCM to avoid rejecting pushes to a subscription with an unknown ID that could be pending in Chrome.

It's interesting that the promise might resolve after 10 minutes... we can't wait that long on a push subscription page, but I'd also guess we can't wait in a service worker, since the worker would presumably be killed well before then. I foresee we might therefore have an issue in a pushsubscriptionchange handler, if the subscribe() call takes too long.

tl;dr - reject isn't a good outcome, but at least it would allow a controlled retry. If website code has to handle a rejection from subscribe(), please (a) document what errors may occur and how they should be handled and (b) try and align them between Mozilla, Chrome and any other browsers :)

If I can reproduce the fault, I'll send a recording. Right now I have no browsers that are suffering the fault, though I can tell from our application server logs that end-users are hitting it.

Hi John

One of our engineers has subscriptions repeatedly failing on one particular website (which works fine for others). We started recording, provoked the failure, and what we see in the GCM internals screen is in the attached screenshot. In summary: we see nothing. We refreshed after the test also, in case the internals page only updates when refreshed, and no change.

Because this website repeatedly fails to subscribe, and because there's no activity shown in the GCM internals logs, I suspect it's not due to a failure to talk to GCM.

Deleted: gcm_internals_screen_shot_2016-10-20_at_3.31.54_pm.png 82.0 KB

	gcm_internals_screen_shot_2016-10-20_at_3.31.54_pm.png 82.0 KB View Download

Hi Ben,

Interesting perspective on retries. It's not currently possible for Chrome to generate a registration ID offline, but that's something we'll think about.

> I can tell from our application server logs that end-users are hitting it.

Could this just be users that are offline or on flaky networks?

> what we see in the GCM internals screen is in the attached screenshot

It looks like Chrome is failing to connect to GCM servers. Could you attach the GCM.* histograms (see comment 30)?

Hi John

Histogram file attached.

In response to your question "Could this just be users that are offline or on flaky networks?" - it's possible, yes. We get our client errors via POSTs to our application server immediately the error occurs, so there must of course be *some* connectivity, but it could be intermittent.

Deleted: gcmHisto.txt 6.9 KB

gcmHisto.txt 6.9 KB View Download

Looking at those histograms, 2/4 of GCM.Database.Open resulted in LEVELDB_STATUS_INVALID_ARGUMENT, 2/4 of GCM.LoadStatus resulted in OPENING_STORE_FAILED, and 1/1 of GCM.ResetStore resulted in INFINITE_STORE_RESET.

Those 3 errors relate to the GCM Store folder getting corrupted in a way we didn't use to be able to recover from, which is fixed in Chrome 55 by  issue 650254 . Presumably your engineer was running Chrome 54?

At the time of the first report, he was running 53.
I guess we can watch for subscribers moving to Chrome 55, and if we see that their subscription attempt ended in an error state, retry the subscription.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5f4601a5426efc4d350963048122d053128dbc0e

commit 5f4601a5426efc4d350963048122d053128dbc0e
Author: johnme <johnme@chromium.org>
Date: Wed Nov 02 12:22:26 2016

GCM Engine: Split up reg/unreg UNKNOWN_ERROR to improve metrics

When the GCM server handles registration/unregistration requests, it can
return several specific error names that Chrome's GCM Engine was lumping
together as UNKNOWN_ERROR. This patch splits them out into distinct enum
values, so we'll be able to compare their occurrence rates using UMA and
get more precise bug reports from users reading chrome://gcm-internals.

UNKNOWN_ERROR should no longer occur... until GCM next add new error
types anyway.

The patch also removes some code duplication between
GCMUnregistrationRequestHandler and InstanceIDDeleteTokenRequestHandler,
but it stops short of merging RegistrationRequest and
UnregistrationRequest since this patch may need to be merged to m55.

There should be minimal functional changes, except that we will no
longer auto-retry QUOTA_EXCEEDED and TOO_MANY_REGISTRATIONS registration
errors, which were unlikely to succeed when retried anyway.

BUG= 623062 

Review-Url: https://codereview.chromium.org/2434243002
Cr-Commit-Position: refs/heads/master@{#429254}

[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/components/gcm_driver/gcm_stats_recorder_impl.cc
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/gcm_unregistration_request_handler.cc
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/gcm_unregistration_request_handler.h
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/instance_id_delete_token_request_handler.cc
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/instance_id_delete_token_request_handler.h
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/registration_request.cc
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/registration_request.h
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/registration_request_unittest.cc
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/unregistration_request.cc
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/unregistration_request.h
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/google_apis/gcm/engine/unregistration_request_unittest.cc
[modify] https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e/tools/metrics/histograms/histograms.xml

Requesting merge of 5f4601a5426efc4d350963048122d053128dbc0e to M55. It's a fairly simple safe patch that mostly just improves our UMA metrics so we can better debug this class of errors. The only functional change expected is that we will no longer auto-retry QUOTA_EXCEEDED and TOO_MANY_REGISTRATIONS registration errors returned by GCM, which were unlikely to succeed when retried anyway (there are other errors that we already don't retry, so this is not a new codepath).

Your change meets the bar and is auto-approved for M55 (branch: 2883)

Re-requesting merge approval, since I realised that this patch has dependencies. I'll need to merge the following 3 patches in order:
1. https://crrev.com/133bfbad6055349368a955d16318c1997d39810b
2. https://crrev.com/f5ee18de1b2485a50255ab83968518b05ea2f359
3. https://crrev.com/5f4601a5426efc4d350963048122d053128dbc0e

(but the dependent patches are even simpler and safer)

Your change meets the bar and is auto-approved for M55 (branch: 2883)

I've cherry-picked the two dependencies:
1. Cherry-picked in https://codereview.chromium.org/2473093002 as
f6af6a205a30cb5d3bc2f9682072c5df85b4660b 2883@{#437}
2. Cherry-picked in https://codereview.chromium.org/2479593004 as
e9a8fe09ec516334c759e9e1a952a98b797926fa 2883@{#438}

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4a8eb7c096a5db1368c4041f17571e3d3771c807

commit 4a8eb7c096a5db1368c4041f17571e3d3771c807
Author: John Mellor <johnme@chromium.org>
Date: Thu Nov 03 18:14:41 2016

GCM Engine: Split up reg/unreg UNKNOWN_ERROR to improve metrics

When the GCM server handles registration/unregistration requests, it can
return several specific error names that Chrome's GCM Engine was lumping
together as UNKNOWN_ERROR. This patch splits them out into distinct enum
values, so we'll be able to compare their occurrence rates using UMA and
get more precise bug reports from users reading chrome://gcm-internals.

UNKNOWN_ERROR should no longer occur... until GCM next add new error
types anyway.

The patch also removes some code duplication between
GCMUnregistrationRequestHandler and InstanceIDDeleteTokenRequestHandler,
but it stops short of merging RegistrationRequest and
UnregistrationRequest since this patch may need to be merged to m55.

There should be minimal functional changes, except that we will no
longer auto-retry QUOTA_EXCEEDED and TOO_MANY_REGISTRATIONS registration
errors, which were unlikely to succeed when retried anyway.

BUG= 623062 

Review-Url: https://codereview.chromium.org/2434243002
Cr-Commit-Position: refs/heads/master@{#429254}
(cherry picked from commit 5f4601a5426efc4d350963048122d053128dbc0e)

Review URL: https://codereview.chromium.org/2474153002 .

Cr-Commit-Position: refs/branch-heads/2883@{#441}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/components/gcm_driver/gcm_stats_recorder_impl.cc
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/gcm_unregistration_request_handler.cc
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/gcm_unregistration_request_handler.h
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/instance_id_delete_token_request_handler.cc
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/instance_id_delete_token_request_handler.h
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/registration_request.cc
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/registration_request.h
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/registration_request_unittest.cc
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/unregistration_request.cc
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/unregistration_request.h
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/google_apis/gcm/engine/unregistration_request_unittest.cc
[modify] https://crrev.com/4a8eb7c096a5db1368c4041f17571e3d3771c807/tools/metrics/histograms/histograms.xml

johnme@ : Could you please let us know if it can be verified from TE end, if so please help with the steps and supportive urls if any.

It's a little tricky to verify, as there are few functional changes, but one thing you can do is:
1. Use a *clean* profile on desktop (and discard it afterwards).
2. Open chrome://gcm-internals/ in a tab.
3. In a different tab, go to https://rawgit.com/johnmellor/75327b6943f551b1048d0e6a3786c5e3/raw/69a1c1e635b8446419120a1b72b0a0cb9855af0f/
4. Click "Subscribe 1001 times"
5. Accept the notifications permission prompt.

EXPECTED (GOOD) RESULTS AFTER PATCH:
The webpage will make about 10 subscribe attempts per second. The numbers in the pending column will vary between 0 and 10 at high frequency, and the number in the success column will rapidly count upwards. Eventually GCM will start rate limiting the device (Chrome profile), and the numbers should stop changing. At this point there should be 10 failures and zero pending, for example I ended up with "Subscribe attempts: 246 success, 10 fail, 0 pending" (but the exact number of successes isn't important, as long as it's > 0). In the chrome://gcm-internals tab you should see that 10 of the most recent registrations received a QUOTA_EXCEEDED response. There probably should *not* be any entries saying REACHED_MAX_RETRIES.

EXPECTED (BAD) RESULTS BEFORE PATCH:
Things will start similarly, but once the numbers stop changing there should be 0 failures and 10 pending subscribe attempts (because we never resolve those promises, or not for a very long time at least). In the chrome://gcm-internals tab you should see that at least 10 of the most recent registrations received an UNKNOWN_ERROR response (because we can't decode them as QUOTA_EXCEEDED yet), along with up to 10 REACHED_MAX_RETRIES entries (because we retry these errors even though they should not be retried).

Verified the fix on Chrome version 55.0.2883.44 on Windows 7 and Mac 10.12.1 with steps provided in comment#47(thanks John).

Would just like to chime in to say that I followed the instructions in comment #47 and I also see the expected working results on Chrome 55 (which is now released!).

http://i.imgur.com/AzUsn9b.png

We're getting reports of what *appears* to be this same defect still showing up in Chrome Canary (57 at the time of writing this comment). Is this expected for a browser that previously showed the issue (and therefore has a corrupted GCM store)?

Hi Ben, which specific issue are you still seeing?

If you're offline, promises will still take up to 10 minutes to be resolved/rejected due to auto-retry (see comment 29, and thanks for your feedback on that in comment 31 - we're still investigating whether we can improve that).

If you mean comment 32 through comment 38, where you had an engineer that could never subscribe and was seeing GCM Store corruption in their chrome://histograms, then  issue 650254  fixed that and it should no longer happen in Chrome 55 or above (except perhaps for users with zero free disk space, or similar I/O issues). It should recover automatically from a previously corrupted GCM Store - if you're not seeing that, then attaching gcm.* histograms from Canary would be very useful.

If you mean Jason's problem in comment 8 (TOO_MANY_REGISTRATIONS), then that should now cause the subscribe promise to be rejected as expected.

If none of the above apply and it's a macOS device, then it might be issue 651863 - check in chrome://gcm-internals/ if it's failing to connect to GCM - and if so more data would be really useful on that bug.

> If you're offline, promises will still take up to 10 minutes to be resolved/rejected due to auto-retry

This may improve a little once we have the pushsubscriptionchange event (issue 646721), as we could potentially deliver that event to the Service Worker once subscription eventually succeeds/fails.

This issue is reproducible on chrome 55.0.2883.87 on Windows 7. The subscribe promise is neither resolving nor rejecting. But this is happening only on one machine with the combination mentioned

Hi Nikhil, could you give us more information to help us debug this?

1. Go to chrome://gcm-internals
2. Click Start Recording
3. Reproduce the problem (subscribe promise neither resolving nor rejecting)
4. Go to chrome://histograms and attach the histograms starting with "GCM." and "PushMessaging." to this bug
5. Go back to chrome://gcm-internals and attach a screenshot here (you may need to scroll and take multiple screenshots; feel free to redact the domain names you were testing with if they happen to be confidential).

Thanks!

Hi All,

Just wanted to say that I was experiencing the same problem as of today with a Mac and Chrome version 61, i.e.:

Calling subscribe() returned a promise in perpetual 'pending' state.

I even opened a SO question before stumbling on this thread:

https://stackoverflow.com/questions/46785424/issue-with-subscribe-method-of-pushmanager

Tried recording with chrome://gcm-internals but it just didn't pick up anything.

The solution was to nuke the GCM Store directory and then restart Chrome.

It worked.

Funny enough, I was experiencing the exact same behavior with Firefox and the solution worked for Firefox too! Very odd, not sure why.

Thanks for your report in #55 mitambur@. It sounds like you reproduced it given that deleting the GCM store fixed it for you, although it is curious that chrome://gcm-internals didn't pick anything up when you experienced the issue, same as the engineer in #32.

Perhaps something else is going on which causes it to hang, unrelated to gcm (as Ben suggested in #32).

Are people still seeing this issue, where deleting the gcm folder fixes things, on recent versions of Chrome? If so, please share the contents of chrome://gcm-internals (redacting anything sensitive) so we can be confident ruling out a gcm error. Thanks.

I'm using chrome Version 68.0.3440.106 (Official Build) (64-bit) on Windows 10 Pro 64bit.
Deleting the GCM Store directory did not work for me. I've uploaded the GCM internals page and histograms are attached.

Deleted: gcm.PNG 33.4 KB

	gcm.PNG 33.4 KB View Download

Deleted: histograms.txt 2.2 MB

histograms.txt 2.2 MB View Download

Hi Joanna - thank you for sharing that data. The histograms show that you didn't respond to the permission prompt for notifications. We require that permission to be granted prior to creating a push subscription, so this is expected behaviour.

Given the age of this bug and the fact that we haven't been able to reproduce it recently, let me close this. Always feel free to open new issues :).