fix: refetch account transaction history when pools resolve - #5796
fix: refetch account transaction history when pools resolve#5796cuzz-venus wants to merge 1 commit into
Conversation
useGetAccountTransactionHistory built its query key from the trimmed params
and the chain ID only, while its query function closed over the pools it
fetches through its own useGetPools({ includeIsolatedPools: true }) call.
Nothing else warms that account-less pools cache entry, so it is always cold
on first mount: the query function ran with getPoolsData undefined, the vToken
asset mapping came out empty, and formatToMarketTransaction discarded every
row. The empty result was then cached under a key that never changed when the
pools resolved, so the Transactions tab kept rendering its "no transactions"
placeholder for every connected account with history.
Derive the sorted vToken addresses from the pools and include them in the
query key, and only run the query once the pools are available, so the history
is fetched against a populated mapping and refetched whenever the listed
assets change.
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThe PR delays account transaction-history fetching until pool data is available and adds the resolved vToken set to the React Query cache key.
Confidence Score: 5/5The PR appears safe to merge with no actionable changed-code defects identified. The revised query lifecycle prevents history from being cached before pool metadata resolves, and the new tests cover the relevant cache-key, loading, error, and disabled states.
|
| Filename | Overview |
|---|---|
| apps/evm/src/clients/api/queries/getAccountTransactionHistory/useGetAccountTransactionHistory.ts | Gates history retrieval on pool availability, fingerprints pool vTokens in the cache key, and composes the dependency loading state without introducing a publishable regression. |
| apps/evm/src/clients/api/queries/getAccountTransactionHistory/tests/useGetAccountTransactionHistory.spec.ts | Covers pending, resolved, changed, reordered, errored, and caller-disabled pool-query states. |
Reviews (1): Last reviewed commit: "fix: refetch account transaction history..." | Re-trigger Greptile
Coverage Report for ./apps/evm
File Coverage
|
||||||||||||||||||||||||||||||||||||||
1 participant
Problem
useGetAccountTransactionHistorybuilt its react-query key from[FunctionKey.GET_ACCOUNT_TRANSACTION_HISTORY, { ...params, chainId }], while its query function closed overgetPoolsDatacoming from its ownuseGetPools({ includeIsolatedPools: true })call.That pools call passes no
accountAddress, so it is a cache entry nothing else on the page warms —pages/Dashboard/Transactionsitself fetchesuseGetPools({ accountAddress, includeIsolatedPools: true }), a different key. The account-less entry is therefore cold at every first mount, by construction:getPoolsData === undefined;vTokenAssetMappingcomes out{}(getAccountTransactionHistory/index.ts:64);formatToMarketTransactionhits its only early exit and returnsundefinedfor every row (formatApiTransaction/formatToMarketTransaction/index.ts:31);The API serves the rows; the dashboard Transactions tab renders "No transactions yet" for every wallet-connected account with history. It does not recover on reload or on a Markets↔Transactions tab round-trip — only a type-filter round-trip more than 10s later (a new key plus a stale entry) brings the rows back.
Fix
In
useGetAccountTransactionHistory:enabled: isEnabled && !!getPoolsData), so it never fetches against an empty mapping — including on the pools-error path, whereisLoadingisfalsebut the data is stillundefined.isLoadingwhile the pools are pending, so consumers show their spinner instead of briefly flashing the empty-state placeholder. It is gated on the caller'senabled, so a disconnected wallet still gets the placeholder rather than an endless spinner, and on the pools error so a hard pools failure resolves instead of spinning.enabledoption toboolean. react-query v5 also accepts a(query) => booleanpredicate, which cannot be resolved here and would have been silently dropped by the&&above.No change was needed in the API layer, the components, or the QA suite's mocks.
Files
apps/evm/src/clients/api/queries/getAccountTransactionHistory/useGetAccountTransactionHistory.tsenabledgate,isLoadingcomposition, narrowed options typeapps/evm/src/clients/api/queries/getAccountTransactionHistory/__tests__/useGetAccountTransactionHistory.spec.tsTests
New hook spec covering both halves of the fix. Each was verified to fail against the unfixed code:
.sort()is removed)Gates
All four run end to end on this branch:
yarn tscyarn lintuseLiteralEnumMemberswarnings in@venusprotocol/chains, non-fatal)yarn extract-translationsyarn test --coverageNote:
src/App/Routes/__tests__/index.spec.tsxflaked once on an intermediate coverage run (afindByTexttimeout on a route whose page component is mocked, so it cannot reach this change). It passes in isolation and the final full run is green at 1849/1849. This flake is pre-existing and was already recorded before this ticket.Ticket
Multica VENUS-177 — Jira VPD-1580 cluster, 19 sub-tasks: VPD-1694, VPD-1733, VPD-1849, VPD-1872, VPD-1873, VPD-1874, VPD-1875, VPD-1876, VPD-1877, VPD-1883, VPD-1884, VPD-1885, VPD-1886, VPD-1887, VPD-1888, VPD-1889, VPD-1890, VPD-1891, VPD-1892 (TC-TXN-007 / 010–027).
Follow-ups (not in this PR)
useGetPools({ includeIsolatedPools: true })whilepages/Dashboard/TransactionsfetchesuseGetPools({ accountAddress, includeIsolatedPools: true })— two cache entries for what is nearly the same data, so the tab waits on a second pools round-trip. Consolidating them touches how pools are cached across the app and is out of scope here.liquidityHubsis still imported into app code from__mocks__/models/liquidityHubs(pre-existing// TODO: fetch from API). Worth a ticket reference on that TODO.