Skip to content

Scope activity-row metadata resolution to the active chain #792

Description

@LeonardEulerXYZ

Summary

Scope asynchronous activity-row metadata resolution to the active chain so network switches cannot display stale token symbols or trigger late registry work from an obsolete row.

This is a non-blocking display-correctness issue. It does not affect transaction construction or execution and has no identified funds-at-risk path.

References

Introduced/exposed by:

Affected paths at the merged revision:

Root cause

resolveSymbol() checks resolvedSymbols before ensureClient() validates whether rpcUrl changed. If an address was resolved on chain A, the same address can return the chain-A symbol immediately after switching to chain B without invalidating the cache.

An older chain-A readErc20StringField() call can also complete after chain-B invalidation and write its result into the new cache because asynchronous completions are not associated with an RPC/chain generation.

Separately, ActivityEventRow starts fetchVaultCategory(address) work without watcher cleanup or an event/chain generation check. A row unmounted or replaced during a network switch can therefore initiate later registry resolution against the new global chain. The registry re-resolves against current state, so this does not automatically write chain-A metadata into chain B, but it creates stale cross-chain work and can compound multi-await chain-switch races.

Reproduction scenarios

Cached symbol

  1. On chain A, resolve an otherwise unknown token address and cache symbol AAA.
  2. Switch to chain B, where the same address has symbol BBB or no token contract.
  3. Render an oracle-route or resolved-vault activity row containing that address.
  4. resolveSymbol() returns cached AAA before observing the changed RPC URL.

Late completion

  1. Start a token-symbol lookup on chain A.
  2. Switch to chain B and trigger cache invalidation.
  3. Allow the chain-A lookup to resolve afterward.
  4. Its completion writes the chain-A symbol into the chain-B cache.

Expected behavior

Activity metadata must be derived from the event/current chain consistently. Results started under an obsolete RPC, chain, event, or component lifecycle must not update the active display cache or registry.

Acceptance criteria

  • Validate/invalidate the RPC or chain generation before reading cached token-symbol results.
  • Associate each asynchronous symbol lookup with its originating RPC/chain generation and discard stale completions.
  • Preserve known unit-of-account labels (USD, EUR, BTC, ETH) and current same-chain caching behavior.
  • Scope the ActivityEventRow vault-category watcher with Vue cleanup or an equivalent { event.id, event.chainId, address } generation guard.
  • Add a regression test for a same-address network switch where chain A and chain B return different symbols.
  • Add a regression test proving an old in-flight completion cannot repopulate the new chain's cache.
  • Add component/effect coverage for initial unresolved rendering, successful async rerender, external-vault registry skip, and stale/unmounted completion handling.

Validation notes

The original #774 validation passed focused tests, the full suite, lint, typecheck, production build, and headed desktop/mobile preview smoke. Existing tests cover synchronous display helpers but do not discriminate these network-switch and component-lifecycle races.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions