MetaMask移动端通知系统迁移问题分析与解决方案

背景概述

MetaMask移动端在7.50.0版本中对其通知系统进行了架构升级，从v1版本迁移到了v2版本。这项升级旨在改进通知服务的性能和可靠性，但开发团队在发布测试阶段发现了一个关键问题：现有已启用通知功能的用户无法自动迁移到新的v2架构。

问题本质

通知系统的架构升级涉及两个主要端点变化：

• 旧架构使用https://trigger.api.cx.metamask.io/v1端点
• 新架构使用https://trigger.api.cx.metamask.io/v2端点

问题表现为：新用户在启用通知时会正确使用v2端点，但已启用通知的现有用户在升级应用后，系统未能自动将其订阅迁移到v2端点。这导致这些用户处于一种"中间状态"——他们的订阅记录仍保留在v1系统，但应用尝试从v2系统获取通知。

影响分析

这一迁移问题会导致以下具体影响：

1. 现有用户将停止接收应用内通知更新
2. 推送通知功能将失效
3. 用户界面可能显示通知已启用，但实际上服务已中断

虽然这不会影响钱包的核心功能，但对依赖通知服务的用户体验造成了显著影响。根据MetaMask的严重性分级标准，这被归类为Sev-2级别问题——影响重要功能但不阻碍主要使用场景。

技术解决方案

开发团队迅速识别了问题根源并实施了修复方案。核心解决思路包括：

1. 强制重新订阅机制：在应用升级时检测用户的通知设置，对已启用的通知强制执行v2端点的重新订阅
2. 版本兼容性处理：确保迁移过程平滑，避免因版本切换导致的数据不一致
3. 错误恢复机制：在迁移失败时提供适当的回退方案

修复验证

修复方案经过以下验证步骤：

1. 在旧版本中创建已启用通知的测试用户
2. 升级到包含修复的新版本
3. 验证网络请求是否正确地发送到v2端点
4. 确认通知功能恢复正常工作

经验总结

这次事件为开发团队提供了宝贵的经验：

1. 数据迁移的重要性：架构升级时需要考虑现有用户状态的迁移策略
2. 版本兼容性测试：新功能发布前需要充分测试与旧版本数据的交互
3. 监控机制：建立完善的功能监控，及时发现类似的功能退化问题

该修复已包含在7.51.0版本中发布，确保了所有用户都能无缝过渡到新的通知系统架构。