这几乎可以肯定是 Discourse 的问题。如果你在几分钟前使用过该网站,它们就不会发送通知。但由于最终用户无法看到这一点,这只会让通知变得不可信。但我向你保证,我收到了这两条消息的 iOS 推送通知。只要你知道永远不要相信它们,它们就可以工作。
我认为问题恰恰相反。最近没有足够频繁地在手机上使用该网站,似乎导致我收不到任何通知。
也许,但我们都只是在猜测。我们需要 Discourse 为最终用户提供足够的日志记录。Discourse 发送了哪些通知?Discourse 决定 不 发送哪些通知?
当 PWA 收到通知时,它可以在设备上的 IndexedDB 中本地记录该通知。用户需要能够查看该日志,并将其与服务器的日志进行关联,以查看 Discourse 何时/是否发送了推送但设备未收到。
但总的来说,我的看法是:不要假设问题出在 Apple,尤其不要假设仅仅等待 iOS 18 就会有帮助。我们需要 Discourse 在这里做些工作,否则一切都不会好转。
我觉得这就像是日志记录非常详细:
这里详细的日志记录可能很容易实现:
“跳过通知 Sam 关于“payload”是因为 Sam 在线。
但如果你只是想调试这个问题,为什么不设置 SiteSetting.push_notification_time_window_mins 为 0 呢?
然后下一级别的日志记录将变得非常非常详细:
- 跳过通知是因为用户启用了“请勿打扰”
- 推送通知提供商超时 discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
- 订阅已过期
- 响应错误
很多事情都可能出错……尽管在任何时候你都可以使用 DE 来验证:查看 push_subscriptions 表以获取最新的 Web 推送订阅。
首先,我想说的是,从我的角度来看,问题在于人们在我的论坛上写道:“我认为推送通知不起作用”,而其他用户则附和说:“是的!我也是!通知肯定坏了/不可靠。”有时他们责怪苹果,有时他们责怪 Discourse,但他们都同意 Discourse 的推送通知是不可靠的。
我很想能够亲自调查这些案例,并说“你没有收到下午 12:31 的通知,原因如下……”但我认为目前这还不可能。
是的,很多事情都可能出错,包括客户端方面的事情,我无法在 DE 中进行调查。
- Service Worker 是否收到了推送事件?
- Service Worker 是否调用了
showNotification? - 是否授予了
showNotification权限,或者showNotification没有起到任何作用? - 设备本身是否设置为“请勿打扰”?
我很希望能有一些面向管理员的文档,解释如何使用 DE 来诊断推送失败,至少能看到通知是否已发送。
但我也认为,保留一个用户可以发送给我的客户端日志,让我能够与 DE 日志进行交叉引用,这将非常有帮助。
首先,至少有一半抱怨这个问题的人并不是他们论坛的管理员。这就是为什么我们需要 Discourse 来实现这一点:
但是,是的,我怀疑将其设置为 0 将消除 80% 的“它不起作用”的抱怨。
总的来说,用户对 Discourse 通知非常不信任。这个问题对于管理员(甚至对于最终用户)来说越容易研究,Discourse 通知就会越值得信赖。
我对这部分有点困惑,我们直接从服务器推送到一个 URL……
这是我的理由。看看这个帖子里用户们在说什么。
这些帖子似乎暗示问题可能出在苹果身上。也许 Discourse 推送到了 URL,但由于某种原因,苹果没有传递推送。为什么会这样呢?
- 也许苹果在推送作业时返回了 4xx 或 5xx 错误,而 Discourse 需要重新推送。
- 也许苹果收到了消息,但无法(或不愿意?)将消息传递给设备。
- 也许设备收到了消息,但苹果没有为服务工作者触发
push事件。 - 也许服务工作者收到了
push事件,但存在一个 bug,它没有调用showNotification(可能不是这个,太明显了……?) - 也许服务工作者收到了
push事件并调用了showNotification,但苹果拒绝显示可见通知。实际上有很多原因可能导致这种情况:- 设备设置为“请勿打扰”(但通知应该最终会显示在通知中心,在这种情况下,我认为是这样)
- 曾经授予的权限,但现在已被撤销(PWA 可以检测这种情况并记录下来!)
- 用户可能已将应用配置为奇怪的通知设置,因此它只推送到通知中心,但不显示横幅
- ……或者苹果因为其他政策原因拒绝显示消息(也许他们认为通知是垃圾邮件?),也许他们会在未来的 iOS 版本中更慷慨一些。
这还没有考虑到 Discourse 本身可能未发送通知的任何原因(请勿打扰、推送过滤器、push_notification_time_window_mins)。
如果我们只能说:“嗯,在下午 12:31,Discourse 向苹果发送了一个 ID 为 XXX 的通知,苹果返回了 201 Created 状态码,但我们不知道之后发生了什么,”那么这些用户/管理员将无法进一步调查。我们只能责怪苹果并放弃推送通知。(“也许 2024 年 iOS 18 的 Web 推送通知会解决这个问题。”)
相反,我们需要能够说:“您的设备上的日志显示,在下午 12:33,服务工作者通过 ID 为 XXX 的通知的推送事件被唤醒,并触发了 showNotification,并且我们可以通过通知 API 看到苹果表示已授予该 XXX 推送的 showNotification 权限。”
(我还认为在 https://meta.discourse.org/my/preferences/notifications 页面上应该有一个“发送测试通知”按钮,允许您 安排 在未来发送通知,例如 N 分钟或 N 小时后,让用户测试“几个小时后不起作用”的情况。)
在我这边,我无法在我的暂存网站上重现此问题。通知在那边工作没有问题。问题出在我的生产网站上。每次启用通知后,它们都会在几个小时内停止工作。我唯一的理论是,也许推送通知的数量可能是一个问题?我的生产网站非常活跃,拥有超过 50,000 名会员,因此我的用户帐户(以及总体而言)会收到大量通知。
我和 @WorldIsMine 做了一个小实验。
- 我们等到他的通知停止工作
- 我们验证了他的推送订阅仍然在
push_subscriptions表中
- 我从 rails 控制台发送了一个推送通知,并确保记录所有异常
u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)
- 没有异常
- 他没有收到
- (为了再次检查,我能够给自己发送一个推送通知)
所以这是苹果方面的问题?会是什么原因呢?
你们有 Mac 电脑可以用于在 macOS Safari 中进行测试吗?你们可以在那里设置开发者工具来调试服务工作线程。
据我所知,这里没有涉及服务工作线程。
不,所有 Web 推送通知都需要 iOS 上的 Service Worker。Sending web push notifications in web apps and browsers | Apple Developer Documentation
好吧,超出我的能力范围了,我不幸的是,在这方面没有客户端经验,也没有 Mac 可用。
至少我们已经排除了服务器端的问题。
啊哈!我想我已经弄清楚了至少一个错误,已在单独的帖子中提交。
尽管我曾希望您的修复能有所改善,但我不太确定。
Meta 已经部署了一周。我在 iPhone PWA 上启用了实时通知。今天……它们突然停止工作了。
它创建于 1 月 5 日。
我将尝试用一个脚本来调试这个问题,看看是什么触发了它并持续了多久,但很多迹象都指向苹果可能存在某种错误。
我越想越觉得 Discourse Hub 现在是 Apple 设备的解决方案。
感谢您跟踪此事!
您是否点击过任何通知?我之所以这样问,是因为我想知道苹果是否会在您收到一定数量的通知但未点击任何通知的情况下,自动关闭网页通知。
我们需要以下功能来分析这些故障:
- 有关如何使用数据浏览器查看推送通知历史记录的说明。
- 设备上的日志,以便我们可以提取这些日志并将其与服务器端日志进行关联。
日志应包括所有push事件的时间戳,包括完整负载,以及Notification.permission状态。 - 一个“发送测试通知”按钮,用于在未来 N 分钟/小时内排队一个通知。
请注意,我的 PWA 通知在过去三周内一直在 Meta 上稳定运行
这是一个令人不安的更新,表明我们在这一战线上将面临更多麻烦:
FYI,@nathank 上面报道的新闻已被苹果公司完全证实。
苹果公司为了“遵守”欧盟的《数字市场法案》(旨在为数字平台带来更多开放性和竞争),采取了公然恶意合规的举动,决定在其即将发布的 Safari iOS 17.4 中彻底淘汰欧盟地区的 PWA。
这将阻止 PWA 安装到主屏幕、使用推送通知、后台同步,并干扰离线存储等功能。而且,由于企业不太可能投资于 Web 应用(尤其是 PWA),因为欧盟地区的 iPhone 用户无法使用它们,这将产生超出欧盟范围的全球性影响。
我不得不认为,这将对许多 Discourse 社区和 Discourse 本身造成重大阻碍。如果这种情况也影响到您,我强烈建议您填写 Open Web Advocacy 组织的这份调查问卷。他们正在领导反对这项政策的斗争,努力让 DMA 团队了解这些以及其他政策对 Web 开发的所有影响。他们正紧急收集将受到这些变化影响的企业提供的证词和数据,以便为 DMA 提供更好的信息来反击。
请访问此页面了解更多信息,填写关于此项变更如何影响您业务的调查问卷,并广为传播!如果 Discourse 能够让其用户意识到即将到来的变化,以便他们每个人都能与 OWA 联系,解释这项变更如何影响他们的业务和社区,那将是极好的。