Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

fix(web): a tab that changes identity doesn't tell the others, which keep writing the previous identity's data

Open
  • Is something wrong?
#706 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
dart, rust
Domain
databases, frontend

Research direction

Start by reading rust/src/ around IndexedDbStorage::clear_identity_data in indexeddb.rs:505, then trace the mentioned save_trade and patch_trade_by_order_id paths and where resetIdentityScopedState runs. The issue leaves cross-tab coordination open, so first compare the proposed approaches and identify the relevant entry points. Done means a two-tab manual check confirms that after an identity change, the other tab cannot write rows for the previous identity.

Written by the indexing model from the issue text.

Description

bug priority: medium

Summary

On web every tab of the origin shares one IndexedDB database, but each tab runs its own Rust core with its own in-memory identity. When one tab replaces the identity (generate or import → delete_identity), it wipes the shared stores (IndexedDbStorage::clear_identity_data, indexeddb.rs:505), but the other tabs are never told. They keep:

  • the previous identity and its trade keys in memory,
  • their relay subscriptions to that identity's trades and daemon messages,
  • their Dart caches (resetIdentityScopedState only runs in the tab that did the wipe).

So the next daemon message one of them handles writes through save_trade / patch_trade_by_order_id, and the previous identity's trade reappears in the new identity's database. Unlike #554, this needs no race: it happens whenever a second tab is open and receives anything.

This breaks the "a new identity starts from zero" rule (#533) on web.

From reading the code, not reproduced yet: I found no cross-tab coordination (BroadcastChannel, storage events, a leader Web Lock) in rust/src/ or lib/.

Steps to reproduce (expected)

  1. Open the web app in two tabs with an identity that has an active trade.

  2. In tab A, generate a new user.

  3. Trigger a daemon message for that trade (or just wait for a reconnect replay) while tab B stays open.

  4. In tab A, check My Trades / IndexedDB trades: the old trade is back.

  5. Broadcast the change. The wiping tab posts on a BroadcastChannel; the others drop their state and reload (or show "identity changed in another tab" and reload on tap). Smallest change; tabs stay usable.

  6. One active tab. A leader Web Lock: only the tab holding it runs the core; the others show "open in another tab". Also removes the other multi-tab write hazards, but changes UX.

Either way the wipe should also take the store locks (#554) so the same-tab case is closed too.

Acceptance

  • After an identity change in one tab, no other tab writes rows of the previous identity.
  • Verified by hand with two tabs (the repo has no wasm test suite yet, see #409).

Related: #554, #533, #408.

Dominant language
Dart
Stars
11
Forks
9
Avg merge
20h 36m
Merged PRs (30d)
236

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MostroP2P/app

All issues in MostroP2P/app

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.