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

fix(web): the identity wipe runs outside the Web Locks section, so a concurrent write can resurrect a trade

Open
  • Is something wrong?
#554 1 comment 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
53/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
database

Research direction

Start with indexeddb.rs: read clear_identity_data and compare its locking with exclusive, save_trade, patch_trade_by_order_id, and the outbox operations. The issue calls for taking patch_serial once and then the trades and outbox origin locks in that order around the wipe. The repository has no wasm test suite; done means the wipe cannot interleave with those writers, with two-tab verification noted as a future check after #409's round-trip tests exist.

Written by the indexing model from the issue text.

Description

bug priority: medium

IndexedDbStorage::clear_identity_data (indexeddb.rs:500) opens its transactions directly. Every writer of a whole document first enters the exclusive section — exclusive() (indexeddb.rs:230), which takes the in-process patch_serial mutex plus the origin-wide lock: save_trade (:300), patch_trade_by_order_id (:252) and the outbox operations, under
TRADES_LOCK / OUTBOX_LOCK (:44-45). The wipe takes neither.

Those writers are read-modify-write: they read the document, change one field and write the whole document back, with awaits in between. That is precisely why #408 added the locks. The wipe can therefore land in the middle of one:

  1. Tab B reads the trade document.
  2. Tab A generates a new user; the wipe commits.
  3. Tab B writes its document back — the previous identity's trade is in the new
    identity's database.

Any tab of the origin shares the database, and the web app is deployed, so two tabs is an ordinary situation; the same shape applies to an in-flight patch in the tab doing the wipe.

Not to be confused with #409, which tracks wasm round-trip tests and the message index and states it does not affect correctness. This one does.

Proposed fix

Enter the exclusive section around the wipe: take patch_serial once — the mutex is not reentrant, so exclusive() cannot simply be called twice — plus both origin locks in a fixed order (trades, then outbox). No other code path holds two of them, so no deadlock is introduced.

Verification

Read-only, since the repo has no wasm test suite. Worth re-checking by hand with two tabs once #409's round-trip tests exist.

Enter the exclusive section around the wipe: take patch_serial once — the mutex is not reentrant, so exclusive() cannot simply be called twice — plus both origin locks in a fixed order (trades, then outbox). No other code path holds two of them, so no deadlock is introduced.

Verification

Read-only, since the repo has no wasm test suite. Worth re-checking by hand with two tabs once #409's round-trip tests exist.

Dominant language
Dart
Stars
11
Forks
9
Avg merge
12h 8m
Merged PRs (30d)
257

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.