fix(wallet): load HIVE/HBD transaction history again - #3480
Conversation
The token history screen asked the node for *every* account operation and then
discarded almost all of it on device. `useActivitiesQuery` called
`getTransactionsInfiniteQueryOptions(username, 50)` with no operation group, so
the SDK fell back to ALL_ACCOUNT_OPERATIONS -- 30 op-type ids including
producer_reward and curation_reward -- against hafah's REST
/accounts/{name}/operations. That broke the screen two ways:
- Empty list on an HTTP 200. For a witness account the newest page of 50 measures
~46 producer_reward + 4 curation_reward. producer_reward is not in
`transferTypes` and curation_reward grooms to "n HP", so HIVE and HBD render
zero rows; the content length never changes, `onEndReached` never re-fires, and
the walk stalls dozens of pages short of the first transfer.
- Query failure. The same wide predicate costs the server seconds to tens of
seconds; cold, api.hive.blog and hiveapi.actifit.io answer HTTP 500 "canceling
statement due to statement timeout" at ~15s, past the 10s client ceiling in
sdk-config.ts. Nothing surfaced the error, so it read as "doesn't load".
Move the Hive layer onto the per-asset SDK queries the web wallet uses
(condenser_api.get_account_history with a server-side operation bitmask) and
request only the operations each tab can actually render. Same account, same
data, 0.2-1.5s instead of 2-28s, and every returned row is renderable.
Two SDK behaviours have to be overridden locally:
- `initialData: { pages: [], pageParams: [] }` exists for the web's prefetched
pages; against mobile's staleTime of 60s that empty seed reads as fresh and
suppresses the first fetch entirely.
- `getNextPageParam` reads `lastPage[lastPage.length - 1].num`, but
get_account_history returns a page in ascending `num` order, so that is the
newest row: pagination advanced one operation per page (49 of 50 rows
duplicated) and yielded -1 at the end of history, the "newest" sentinel, which
restarted the walk and never terminated.
Also in this change:
- Surface isError/error from the hook and render a real empty/failed state, so a
failed load no longer looks identical to an empty history.
- Auto-advance up to 5 pages while nothing renders, for the case where a page is
legitimately filtered down to zero rows.
- Accept VESTS on the HP tab, so delegate_vesting_shares and
fill_vesting_withdraw stop being dropped by the ticker match.
- Enable useRecurringActivitesQuery again: callers pass the symbol ('HIVE') but
it gated on ASSET_IDS.HIVE ('hive'), so it never ran and the coin summary was
stuck on zero recurrent transfers.
- Stable list keys, explicit section keys, onEndReachedThreshold, and a
ref-backed AppState handler that no longer restarts an in-flight refetch.
Known gaps left alone: the SDK's per-asset `select` still hard-drops
fill_transfer_from_savings and escrow_* on the HIVE/HBD tabs, and
ALL_ACCOUNT_OPERATIONS lists fill_recurrent_transfer twice while omitting
fill_transfer_from_savings. Both need an SDK release.
|
Warning Review limit reached
Next review available in: 40 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughWallet history now uses asset-specific SDK queries and operation filters for HIVE, HBD, and Hive Power. It adds bounded pagination, explicit loading and failure states, stable activity keys, foreground refresh handling, localization, and wallet-history tests. ChangesWallet history activity flow
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant AssetDetailsScreen
participant walletQueries
participant SDKTransactionQuery
participant ActivitiesList
AssetDetailsScreen->>walletQueries: request activity history
walletQueries->>SDKTransactionQuery: query asset operations
SDKTransactionQuery-->>walletQueries: return paged transactions
walletQueries-->>AssetDetailsScreen: return activities and request state
AssetDetailsScreen->>ActivitiesList: pass activities and failure state
ActivitiesList-->>AssetDetailsScreen: render rows or status message
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 55553d3feb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ]; | ||
|
|
||
| export const HIVE_LAYER_HISTORY_OPS: Record<string, HiveOperationFilterValue[]> = { | ||
| HIVE: [...BASE_HISTORY_OPS, 'transfer_to_vesting', 'fill_order', 'fill_convert_request'], |
There was a problem hiding this comment.
When an account receives a normal power-down installment, fill_vesting_withdraw carries a HIVE-denominated deposited value that groomingTransactionData and the HIVE ticker filter can render. The new server-side mask requests this operation only for HP, so these liquid-HIVE credits—previously included by the ungrouped history query—disappear from the HIVE transaction history. Include fill_vesting_withdraw in the HIVE operation set as well.
Useful? React with 👍 / 👎.
| const query = useQuery({ | ||
| ...getRecurrentTransfersQueryOptions(username || ''), | ||
| enabled: coinId === ASSET_IDS.HIVE && !!username, // Only fetch for HIVE and when username exists | ||
| enabled: isHiveAsset && !!username, // Only fetch for HIVE and when username exists |
There was a problem hiding this comment.
When an account has recurrent transfers in both HIVE and HBD, enabling this query for the HIVE symbol fetches every recurrent transfer because the SDK query is scoped only by username. The reducer below then sums parseFloat(item.amount) without checking its symbol, while CoinSummary labels the result as HIVE; for example, 1 HIVE plus 10 HBD is displayed as 11 HIVE, and the HIVE modal also exposes both assets. Filter the returned transfers by coinId before summing and exposing them.
Useful? React with 👍 / 👎.
|
SDK follow-ups are up as ecency/vision-web#1396 — cursor direction, the Once that ships, the two local overrides in
|
…transaction-history
… override 2.3.80 (ecency/vision-web#1396) carries the account-history fixes this branch was working around: - The cursor now walks back from the OLDEST row on the page, so the local `getNextPageParam` override is redundant. Removed it, along with `getNextHistoryPageParam` and its tests -- the SDK owns and tests that contract now, and a second copy here could silently override a future SDK change. - The per-asset `select` no longer discards operations the caller asked for by name, and `fill_transfer_from_savings` is back in the transfers group, so it is finally requestable. Added it to the HIVE/HBD set: `transferTypes` and `groomingTransactionData` already render it, so a completed savings withdrawal now shows up in the history instead of never arriving. `initialData: undefined` stays. 2.3.80 removed the seed, but no SDK test pins its absence and the failure it causes is invisible -- an empty list for the length of staleTime, with no error -- so it is worth keeping as a guard. Comment reworded to say so. yarn typecheck clean, yarn test:ci 812 passed / 1 skipped.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/utils/walletHistory.test.ts (1)
25-40: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAssert savings-completion operation membership.
The tests verify that listed operations are valid. They do not verify that
fill_transfer_from_savingsremains in the HIVE and HBD sets. Removing that operation would still pass these tests and would reintroduce missing completed savings withdrawals.Proposed test
+ it('includes completed savings withdrawals for liquid assets', () => { + expect(HIVE_LAYER_HISTORY_OPS.HIVE).toContain('fill_transfer_from_savings'); + expect(HIVE_LAYER_HISTORY_OPS.HBD).toContain('fill_transfer_from_savings'); + }); +🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/utils/walletHistory.test.ts` around lines 25 - 40, Update the tests for HIVE_LAYER_HISTORY_OPS to explicitly assert that both the HIVE and HBD operation sets contain fill_transfer_from_savings, while preserving the existing validity and renderability checks.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/utils/walletHistory.ts`:
- Around line 64-70: Update matchesAssetTicker to normalize transfer_to_vesting
activity values from HIVE into HP before applying the existing ticker filtering,
so vesting amounts such as “10.000 HIVE” match the HP tab. Add a regression test
covering a transfer_to_vesting value with the HIVE ticker and asserting it
matches HP.
---
Nitpick comments:
In `@src/utils/walletHistory.test.ts`:
- Around line 25-40: Update the tests for HIVE_LAYER_HISTORY_OPS to explicitly
assert that both the HIVE and HBD operation sets contain
fill_transfer_from_savings, while preserving the existing validity and
renderability checks.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 6c1cbc81-d25e-473d-b0de-7f274e724fe5
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (8)
package.jsonsrc/config/locales/en-US.jsonsrc/providers/queries/walletQueries/walletQueries.tssrc/screens/assetDetails/children/activitiesList.tsxsrc/screens/assetDetails/children/children.styles.tssrc/screens/assetDetails/screen/assetDetailsScreen.tsxsrc/utils/walletHistory.test.tssrc/utils/walletHistory.ts
Three findings, all real. **Power-down payouts vanished from the HIVE tab (Codex P2).** A normal power-down installment emits `fill_vesting_withdraw` whose `deposited` is HIVE-denominated, and both `transferTypes` and the ticker match render it — the old ungrouped query returned it, so those rows used to show on HIVE. The per-symbol mask requested op 56 only for HP, dropping them. Added it to the HIVE set; the routed-to-vesting variant denominates `deposited` in VESTS, so the ticker match keeps sending that one to HP. **Power-ups never reached the HP tab (CodeRabbit).** `transfer_to_vesting` is groomed to the HIVE amount that went in, so a ticker match alone excluded it from HP even though the tab requests it — and web's HP view shows it. Added STRUCTURAL_OPS for operations that belong to a tab by nature rather than by denomination. Pre-existing, but the tab now pays to fetch the operation, so it should render it. **Recurrent-transfer totals mixed symbols (Codex P2).** The SDK query is scoped to the account, not an asset, so it returns every schedule. The reducer sums bare `parseFloat` values and CoinSummary labels the result HIVE: 1 HIVE plus 10 HBD displayed as "11 HIVE", and the modal listed HBD schedules under HIVE. Latent until the previous commit fixed the enable-gate, so this ships with it. Filtered in `select` so both the total and the modal see only the tab's asset. Tests cover each: op-set membership for both savings completions and power-down payouts, a power-up matching HP and HIVE but not HBD, and each power-down variant routing to the tab matching its denomination. yarn typecheck clean, yarn test:ci 816 passed / 1 skipped.
Picks up the account-history follow-ups from ecency/vision-web#1404, on top of the pagination fix #3480 already relies on. - the history walk can reach the head of an account's history instead of failing the node's `start >= limit - 1` assert on the last page - `fill_transfer_from_savings` is filtered by asset, so the HIVE list no longer shows completed HBD savings withdrawals and the reverse
1 participant
Opening the HIVE or HBD token screen showed no transaction history.
Cause
useActivitiesQuerycalledgetTransactionsInfiniteQueryOptions(username, 50)with no operation group, so the SDK fell back toALL_ACCOUNT_OPERATIONS(30 op-type ids, includingproducer_rewardandcuration_reward) against hafah's REST/accounts/{name}/operations. That produced the symptom two ways:Empty list on an HTTP 200. Measured on
good-karma: the 30-id filter matches 5.86M operations, ~81% of themproducer_reward. The newest page of 50 came back as 46producer_reward+ 4curation_reward.producer_rewardis not intransferTypes, andcuration_rewardgrooms to"n HP", so HIVE and HBD rendered zero rows. Because the page added nothing, the list's content length never changed,onEndReachednever re-fired, and the walk stalled ~62 pages short of the first transfer. HP still worked, which is why the report named HIVE and HBD only.Query failure. The same wide predicate is expensive server-side. Cold, per node, for that exact request:
57014 canceling statement due to statement timeout@ 15.3ssdk-config.tssets a 10s client ceiling, and the REST pool is the SDK default order, so the walk starts on the two slowest hosts and gives up before reaching the fastest. Nothing surfaced the error, so a failed load looked identical to an empty one.Change
Moves the Hive layer onto the per-asset SDK queries the web wallet already uses (
condenser_api.get_account_historywith a server-side operation bitmask) and requests only the operations each tab can actually render. Same account, same data: 0.2-1.5s instead of 2-28s, and every returned row is renderable (good-karmaHIVE page 1 goes from 0 usable rows to 50).Two SDK behaviours are overridden locally, both load-bearing:
initialData: { pages: [], pageParams: [] }exists for the web's prefetched pages. Against mobile'sstaleTime: 60_000that empty seed reads as fresh data and suppresses the first fetch entirely.getNextPageParamreadslastPage[lastPage.length - 1].num, butget_account_historyreturns a page in ascendingnumorder, so that is the newest row. Verified live: page 1 and page 2 overlapped by 49 of 50 rows. At the end of history it yields-1, the "newest" sentinel, restarting the walk forever.Also fixed along the way:
useActivitiesQuerynow returnsisError/error, and the list renders a real empty/failed state instead of a bare header.VESTS, sodelegate_vesting_sharesandfill_vesting_withdrawstop being dropped by the ticker match.useRecurringActivitesQueryruns again: every caller passes the symbol ('HIVE') but it gated onASSET_IDS.HIVE('hive'), so it was permanently disabled and the coin summary was stuck on zero recurrent transfers.onEndReachedThreshold, and a ref-backed AppState handler that no longer restarts an in-flight refetch.Tests
New
src/utils/walletHistory.test.ts(15 tests) covers the cursor direction and its termination atnum === 0, the ticker match including VESTS on HP, a contract test asserting every requested operation name exists on-chain and is renderable bytransferTypes+groomingTransactionData, and a witness-account fixture page asserting HIVE and HBD each yield rows andproducer_rewardnever does.yarn typecheckclean,yarn test:ci753 passed / 1 skipped.Follow-ups for @ecency/sdk
Not on the critical path, needs a separate release:
getNextPageParaminget-hive-asset-transactions-query-options.tsis wrong for web too (it currently re-fetches 49 duplicate rows per page).ALL_ACCOUNT_OPERATIONSlistsfill_recurrent_transfertwice and omitsfill_transfer_from_savings.producer_reward, orgroupshould be required.selecthard-dropsfill_transfer_from_savingsandescrow_*on HIVE/HBD even when explicitly requested, so those rows can't be shown from the client side.Summary by CodeRabbit
New Features
Bug Fixes