feat(web): paginate the audio transactions page#14381
Merged
Merged
Conversation
AudioWalletTransactions.tsx requests pageSize = audioTransactionsCount
to render every transaction in one shot (the table has no pagination
UI). For users with more than 100 transactions, this exceeds the
server-side validator on /v1/users/{id}/transactions/audio (limit: max=100)
and the request fails outright — power users see an empty page.
Cap the requested page size at 100. Users with more than 100 now see
the most recent 100; users with fewer keep current behavior.
A proper "load more" affordance is the right long-term fix; this is
just stopping the bleeding.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Replaces the "fetch everything in one shot, capped at 100" workaround with proper infinite pagination, matching the pattern used by the USDC purchases / sales / withdrawals tables. - useAudioTransactions: convert from useQuery to useInfiniteQuery, expose loadNextPage with a stable identity (same shape as usePurchases). pageSize defaults to 50, requested per page. - AudioWalletTransactions: drop the audioTransactionsCount-based pageSize hack and the Math.min(..., 100) clamp from the previous commit. Wire fetchMore + totalRowCount + isVirtualized into AudioTransactionsTable so it loads more rows as the user scrolls. The previous commit's clamp is no longer needed — the new hook always requests pageSize<=50 per page. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
rickyrombo
changed the title
Contributor
🌐 Web preview readyPreview URL: https://audius-web-preview-pr-14381.audius.workers.dev Unique preview for this PR (deployed from this branch). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replaces the "fetch everything in one shot" pattern on the AUDIO transactions page with proper infinite pagination, matching what the USDC purchases / sales / withdrawals tables already do.
Background
`AudioWalletTransactions.tsx` was setting `pageSize = audioTransactionsCount` so the table could render every transaction in a single fetch (the table has no built-in pagination UI). For users with more than 100 transactions, this exceeded the server-side validator on `/v1/users/{id}/transactions/audio` (`limit` max=100), and the request failed outright — power users saw an empty page.
The first commit on this branch just clamped the requested size at 100 (stopping the bleeding). This second commit replaces the workaround with real pagination.
Changes
`useAudioTransactions` (`packages/common`)
`AudioWalletTransactions.tsx` (`packages/web`)
Server-side win
This also bounds the worst-case input to the slow `ORDER BY transaction_type` plan I flagged in api#844: the server can now never be asked for more than 50 rows per request, capping the cost of the materialize-and-sort plan.
Test plan
🤖 Generated with Claude Code