Note: same behaviour on Chrome v62 on Android 8.0

Thanks for reporting a bug! :)
However, I think it could be expected behavior. 
IIUC, generally android in doze mode (deep-sleep mode) periodically wakes up and goes to the maintenance mode. In the maintenance mode, network gets turned on and notifications are received. I could confirm chrome follows the basic behavior.

You can confirm it as follows:

$ adb shell dumpsys battery unplug
$ adb shell dumpsys deviceidle enable

- Register a service worker and subscribe notification
- Turn off the screen

$ adb shell dumpsys deviceidle step
Stepped to deep: IDLE_PENDING
$ adb shell dumpsys deviceidle step
Stepped to deep: SENSING
$ adb shell dumpsys deviceidle step
Stepped to deep: LOCATING
$ adb shell dumpsys deviceidle step
Stepped to deep: IDLE

- Send notification from my desktop. Nothing happens. (1)

$ adb shell dumpsys deviceidle step
Stepped to deep: IDLE_MAINTENANCE

- Receive the notification.

Ah, but even in the deep sleep mode, should high priority messages be handled? 
I'm not quite familiar with the push messaging policy. +peter for confirmation.

Yes high priority messages should be able to punch through doze mode (even "deep" doze).

I'll double check if the message is processed once the device returns to "normal" operations. I assumed that once I put the device into deep doze via adb, it should leave doze automatically when I turn on the screen? Because if it does/should (recover from doze when I turn on the screen), then I'm pretty sure the message is never received in my Service Worker after I turn on the screen and unlock my phone. I tested that.

Is there a separate command to wake the device from doze after putting it into deep sleep? As I stated, I used these cmds:
"adb shell dumpsys deviceidle enable" and "adb shell dumpsys deviceidle force-idle"

Is there any chance this is related to  issue 764437 ? I'm guessing no because Android shouldn't be in a "deep sleep" mode when you're tapping a notification.

Re c#4:
$ adb shell dumpsys deviceidle force-idle
As far as I could confirm, the command above enforces the device goes into the doze mode, so it cannot return to the normal mode until you cancel force-idle (adb shell dumpsys deviceidle unforce). If you want to check how the mode transition happens, it'd be better to use "step" command like c#2.

Re c#5:
I guess it's not related, too, unless the device somehow goes into the deep sleep mode while screen is on. I couldn't reproduce the 10 sec delay during checking the notification. Even just after deep sleep, tapping notification took only several (2 or 3) seconds (though it might be a bit slow).

Re c#6: Thanks, that seems to work. As soon as I unforce doze the message is received and a notification is shown. Hmm. I do have a problem with notifications not showing up "in real world situations" and it seems to be related to doze but it's kinda hard to debug because it's a mobile and I often can't hook my phone up to a laptop and check the console when I notice it. I don't see this problem on other devices running older versions of Android.. Anyway, this is just part of the problem. I'll try and produce a clearer case of this problem.

The other thing is: High priority push messages from FCM _should_ punch through doze according to the docs:

"If your users must see a notification right away, make sure to use an FCM high priority message."
https://developer.android.com/training/monitoring-device-state/doze-standby.html

Since the SW doesn't do anything when the device is put into doze this seems to be broken?

I added a breakpoint to onMessageReceived in our ChromeGcmListenerService, attached a debugger, and tried sending a message when the device is in idle mode following the steps in #2. 

The breakpoint only gets hit once the device enters IDLE_MAINTENANCE mode.

I am not sure if this is WAI. But at least it rules out a bug in the job-scheduling code which wakes up the service worker after that point.

Update: spoke to the GCM team and this is not WAI. They are looking into it, internal bug is b/68751004 

I take that back - I wasn't setting Urgency: high in #10.

Indeed now that I am setting urgency: high the breakpoint is hit immediately as expected.

Will investigate further tomorrow.

OK so just to update this thread - the bug does seem to be in Chrome code after all.

On receiving the gcm push message we schedule a job on N and above to handle it[1]. Although we give the job a delay of 0ms, this is not enough to make the job run immediately when the device is in deep sleep.

We are discussing potential ways round this on the internal bug (b/68751004).

[1] https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/services/gcm/ChromeGcmListenerService.java?l=102

Any news on this?

And sorry for asking the dumb question but.. other (Google) apps can handle high priority FCM messages just fine (maybe even the combination? Inbox? Gmail? Calendar?) so maybe it's an idea to go ask another team? (I am actually quite curious why Chrome uses a Job Scheduler and doesn't "just show" the notification but alas a bug tracker is probably not the best place to discuss such a thing? :)

PS: I just added Chrome to the list of "not optimized" in Battery Optimization settings. That seems to fix the problem (I do receive notifications now).

I also want to re-iterate/remind that (without the workaround I just mentioned) any messages after the first one never fire the onPushMessage event in the Service Worker when the device does come out of deep sleep.

So:
- Go into deep sleep
- Send a push message
- Send another one
- Step into maintenance or out of sleep
- The first message is received in the SW
- The second isn't

Re #14, Chrome doesn't 'just show a notification' in response to a push event because Chrome doesn't know what notification should be shown yet.

What instead happens is:

1. Chrome receives a push message via gcm in the ChromeGcmListenerService

2. Chrome schedules a job (on N+O) to start up the browser process (if necessary) and deliver the push message to the service worker. Note, this may take more than 10s, hence scheduling a job.

3. The service worker then has a limited window of execution within which it must show a notification, if it is not in the foreground (which it would not be if the device is in deep sleep). 

We have been discussing this issue with the GCM and Android teams. It turns out that if the message is high priority then we can start a service without showing a notification, subject to certain restrictions (no network activity for the first 10s; upper bound of ~1min execution). 

So we are considering starting the service directly instead of scheduling a job in response to high priority push messages, ie using the same code path as the one we use on older versions of Android which have no notification requirement for starting services from the background.

Thanks for the update 👍

Any news on this? It's been a while ;)

Yeah the high priority messages still don't seem to wake up the phone.