Skip to content

Verify wallet transaction history on a device: the fix shipped without a device pass #3489

Description

@feruzm

The HIVE/HBD transaction history fix shipped across #3480 and #3487 (with @ecency/sdk 2.3.80 and 2.3.81) was proven entirely at the API layer — live curl/RPC measurement against real accounts plus unit tests. Nobody opened the wallet screen on a build and watched the list populate. The original report was a device symptom, so that is the check that actually closes it.

Filing this so the gap is tracked rather than assumed closed.

What to check

On a logged-in build, for both a small account and one with a large history (a witness account is the useful stress case — the original failure needed ~5M operations to reproduce):

  • Wallet → HIVE → the activity list populates. Before the fix this was empty on an HTTP 200, because the newest page came back ~92% producer_reward, which the client drops.
  • Wallet → HBD → same.
  • Wallet → HP → still populates, and delegate_vesting_shares / power-down rows appear (they are VESTS-denominated and were previously filtered out).
  • A power-up (transfer_to_vesting) appears on both HIVE and HP.
  • A completed savings withdrawal (fill_transfer_from_savings) appears on HIVE/HBD — newly requestable as of sdk 2.3.80.
  • Scroll to trigger pagination: no duplicate rows, and it terminates at the start of history rather than looping. Both were real bugs in the SDK cursor.
  • Pull to refresh works, and the spinner resolves.
  • Kill the network and open a token: the list shows the failure message, not a silent empty state. Before the fix a failure and an empty history were indistinguishable.
  • HIVE token detail shows a non-zero recurrent-transfer total when the account has HIVE schedules, and the modal lists only HIVE ones. That query was permanently disabled before fix(wallet): load HIVE/HBD transaction history again #3480 (gated on 'hive' while callers pass 'HIVE'), so this path has effectively never run in production.

Note on CI

The Android and iOS builds never reported on a commit containing this change — the runs on the merge commit and the one after were cancelled by concurrency when newer pushes landed. Lint, typecheck and unit tests were green throughout, and the change is pure TS with no native surface, so this is a gap in the record rather than a suspected problem. Worth confirming the current development builds are green as part of this.

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