Persist FID registration and refresh weekly#9796
Persist FID registration and refresh weekly#9796zwu52 wants to merge 8 commits intofeat/messaging-api-seriesfrom
Conversation
- Persist the last successful FID registration time in IndexedDB and refresh backend registration on a 7-day cadence even when the FID is unchanged - Fall back to opening DB v1 when opening/upgrading to v2 fails, so existing token data remains readable (guarded by a unit test) - Extend register() tests to cover weekly refresh without re-firing onRegistered Made-with: Cursor
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request implements a weekly refresh mechanism for FCM registration by tracking the last registration time in IndexedDB. It includes a database schema update to version 2 with a new object store and a fallback mechanism for failed upgrades. Review feedback identified a race condition and missing multi-tab 'blocking' handlers in the database initialization logic, along with a bug in the database deletion process that could prevent recovery from a corrupted state.
If the cached dbPromise is rejected (e.g. corrupted IndexedDB), dbDelete previously threw before calling deleteDB, preventing recovery. Always attempt deleteDB and add a regression test.
| 'CreateRegistration succeeded but response body is not valid JSON' | ||
| }); | ||
| } | ||
| const fid = data.name; |
There was a problem hiding this comment.
name is not just a fid. See my previous comment. You can address this in your next PR if you prefer.
2 participants
1. Enhanced Token Persistence & Lifecycle
2. Robust Database Migration & Fallback
3. Expanded Test Coverage
register()test suite to validate the new weekly refresh behavior.onRegisteredevent.Summary of Changes
lastRegistrationTimeto IndexedDB schema.currentTime - lastRegistrationTime > 7 days.try-catchon DB v2 initialization with a v1 recovery path.onRegisteredsuppression.