fix(persistence): drop the cached transaction history on upgrade - #1284
Closed
bmc08gt wants to merge 1 commit into
Closed
fix(persistence): drop the cached transaction history on upgrade#1284bmc08gt wants to merge 1 commit into
bmc08gt wants to merge 1 commit into
Conversation
Bumps the DB to v29 with a data-only auto migration that clears the `messages` table. The feed is a cache of the server's activity history, not a source of truth: FeedRemoteMediator clears and re-fetches it on every REFRESH, so an emptied table repopulates on the next load. Rows written by older mappers, though, are never rewritten once the server stops sending that notification — so stale metadata, amounts, and substitutions render forever. Clearing on upgrade sheds them. There is no schema change, so this rides the auto migration and does its work in onPostMigrate (same shape as Migration22To23). It takes the SQLiteConnection overload rather than the SupportSQLiteDatabase one: the latter only fires when Room is built without a driver, so a future setDriver would turn the delete into a silent no-op. The wallet already distinguishes "no activity" from "haven't looked yet" via ActivityFeedCoordinator.syncState, so the empty window before the first fetch doesn't flash new-user onboarding at an established user.
bmc08gt
added a commit
that referenced
this pull request
Aug 20, 2026
Folds in the standalone migration work from #1284, which duplicated the 28 -> 29 clear this branch already carries. Adds TransactionHistoryMigrationTest, following the hand-rolled pattern in UserProfileMigrationTest: asserts the feed is emptied, that a neighbouring table survives, and that it's a no-op on an already-empty feed. Also switches Migration28To29 to the onPostMigrate(SQLiteConnection) overload. Room's SupportSQLiteDatabase variant only fires when the database is built without a driver, so a future setDriver would turn the delete into a silent no-op.
Collaborator
Author
bmc08gt
added a commit
that referenced
this pull request
Aug 20, 2026
* fix(activity): show Convert transactions in the feed
A swap spans two mints, so the backend leaves `payment_amount` unset and carries
both amounts in `additional_metadata` instead. `ActivityFeedMessageMapper` only
ever read `payment_amount`, so every Convert cached with a null amount, rate, and
mint — which meant it matched no token's activity query and rendered blank in the
global feed.
- Map multi-mint amounts from `additional_metadata` when `payment_amount` is absent.
- Attribute a Convert to *both* mints, so it appears on the source and destination
token screens (`MintInvolvement` + the metadata clause in `observeRecentForMint`).
- Render it the way iOS does: overlapping dual-token avatar, from-amount on top,
`-<fee> Fee` beneath.
- Title the row with the two token names ("Moony -> Jeffy") rather than the
server's bare "Converted", falling back to the server text until both tokens
resolve.
Rows cached before this can't be repaired in place (the amounts were never
persisted) and can't be re-fetched either, since sync only walks forward from the
newest cached id. DB 28 -> 29 clears `messages` so the next sync re-seeds from
scratch — the same approach as the existing 1->2, 6->7, 7->8 and 9->10 migrations.
Also fixes a silent data-loss path found alongside it: `MessageDataSource.upsert`
no-oped when the per-user DB wasn't open yet, discarding a whole fetched page
while the coordinator still reported `Synced`. Because every sync path pages
forward from the newest cached id, those notifications were never requested
again. It now fails loudly (matching `observe()`, which already errors on a
missing DB), the mediator turns that into a retryable error, and the coordinator
only reports `Synced` once the write has actually landed.
* test(persistence): cover the v29 feed-clearing migration
Folds in the standalone migration work from #1284, which duplicated the
28 -> 29 clear this branch already carries.
Adds TransactionHistoryMigrationTest, following the hand-rolled pattern
in UserProfileMigrationTest: asserts the feed is emptied, that a
neighbouring table survives, and that it's a no-op on an already-empty
feed.
Also switches Migration28To29 to the onPostMigrate(SQLiteConnection)
overload. Room's SupportSQLiteDatabase variant only fires when the
database is built without a driver, so a future setDriver would turn the
delete into a silent no-op.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the DB to v29 with a data-only auto migration that clears the
messagestable.Why
The feed is a cache of the server's activity history, not a source of truth —
FeedRemoteMediatorclears and re-fetches it on every REFRESH, so an emptied table repopulates on the next load.Rows written by older mappers, though, are never rewritten once the server stops sending that notification. Stale metadata, amounts, and substitutions render forever. Clearing on upgrade sheds them.
How
There's no schema change, so this rides the auto migration and does its work in
onPostMigrate— the same shape as the existingMigration22To23. The generated29.jsonis byte-identical to28.jsonapart from the version (sameidentityHash), which is what makes the empty auto-migration valid.It takes the
onPostMigrate(SQLiteConnection)overload rather than theSupportSQLiteDatabaseone: the latter only fires when Room is built without a driver, so a future.setDriver(...)would turn the delete into a silent no-op. (Migration22To23has the same latent issue; left alone since it works as currently configured.)Onboarding milestone
Clearing the table transiently resets
hasEverReceivedMoney(), which drives the wallet's "added money" tutorial item. That's the same state as a fresh install, andActivityFeedCoordinator.syncStatealready exists to distinguish "empty account" from "haven't fetched yet" — so a returning user doesn't get flashed new-user onboarding in the window before the first fetch lands.Tests
TransactionHistoryMigrationTestfollows the hand-rolled pattern inUserProfileMigrationTest: asserts the feed is emptied, that a neighbouring table (blocked_users) is untouched, and that it's a no-op on an already-empty feed.