为什么我的一些旧版 GCM/FCM PushManager 实例在 chrome://gcm-internals 中出现 HTTP_NOT_OKAY 失败？

Question

多年来，我一直在使用 Google Cloud Messaging (GCM)。 几年前，我“迁移”到Firebase云消息传递 (FCM) ，据我所知，这就是 web 应用程序迁移所需的全部内容。

我正在使用 Google App Engine (GAE) 在新事件发生时发送推送通知（每天最多几次），使用“旧版”HTTP API，如下所述：Z5E056C500A1C4B6A7110BADED.com875Zfirebase.googleD.com /docs/cloud-messaging/http-server-ref这通常已经工作了多年。

最近，我有一位客户报告了一个问题，即在他暂时禁用推送通知后无法重新订阅推送通知。

我部署了许多使用这种模式的应用程序，最旧的应用程序似乎继续正常工作，但较新的应用程序在过去一个月左右停止允许新注册。

故事的简短版本是，当 service worker 尝试通过registration.pushManager.subscribe()订阅时，呼叫挂起一分钟（在桌面上）或几乎立即（在移动设备上）报告错误，说Registration failed - push service error 。

检查 chrome://gcm-internals，我注意到我的一个项目（ 289880423978/GCM ）总是以HTTP_NOT_OK失败，而另一个（ 412646196147/GCM ）总是以SUCCESS （见下面的截图）。

chrome://gcm-internals 只提供HTTP_NOT_OK和一些失败的重试信息，据我所知，这不是我的错。

正在工作的和损坏的都是 Java 8 个启用 Firebase 的 GAE 项目（用于使用 Cloud Functions 的不相关目的）。 两者都根据项目的需要在manifest.json中设置gcm_sender_id 。

现在，看，我知道我可以切换到 VAPID 等并重新做我的推送通知系统。 它在我的名单上。 问题是切换applicationServerKey （很像切换gcm_sender_id ）会丢失用户的令牌，这意味着我无法在没有数据丢失和给用户带来不便的情况下进行切换。

我绝对最后的解决方案是向我的所有用户发送电子邮件，并要求他们在部署 VAPID 代码后重新加载站点并重新注册，但是由于registration.pushManager.subscribe()悄悄地失败了，我没有办法map 之前的注册（连同它的所有设置）对应于用户当前的设备（我在后面使用发件人URL的随机ID来识别设备）； 因此，我无法提供无缝迁移。 除非绝对必要，否则我真的希望避免采取如此激烈的行动，但我一整天都在排除故障，我无法弄清楚出了什么问题。

有谁知道为什么在manifest.json中使用gcm_sender_id时服务工作者会在registration.pushManager.subscribe()调用期间失败？