fix: remove orphaned, mainnet-hardcoded useStellarAccount hook#33
Merged
abayomicornelius merged 8 commits intoJul 17, 2026
Conversation
useStellarAccount hardcoded https://horizon.stellar.org (mainnet) regardless of the user's selected network, unlike WalletContext's network-aware fetchAccountFromHorizon(publicKey, network). It also had zero call sites anywhere in the app and returned a narrower ad-hoc { address, balance, sequence } shape that duplicates the real AccountInfo type in src/types. Per the issue's own suggested resolution, deleting a dead, network-unaware duplicate is preferable to fixing it in place and maintaining two parallel account-fetching implementations — useWallet's account state (backed by fetchAccountFromHorizon) already covers this correctly.
The network-selection bug in StellarSend#21 lived in a hook that duplicated this exact logic without testing or reusing it. horizonUrl is the real, correct implementation everything should route through — give it coverage so a future regression here is caught directly.
This is the request path that useStellarAccount should have delegated to instead of hardcoding the mainnet host. Assert the request URL actually varies with the network argument, mocking global fetch.
Confirms a missing account (the exact symptom this issue's testnet addresses hit against the wrong, hardcoded mainnet host) surfaces as a readable 'Account not found on Stellar network' error.
Non-404 failures (rate limiting, Horizon downtime, etc.) should still surface a readable message rather than an unhandled rejection.
One of StellarSend#21's complaints about useStellarAccount was that it only surfaced the native XLM balance and none of an account's thresholds/ flags/other-asset balances. Assert fetchAccountFromHorizon — the implementation everything should use instead — actually returns the full AccountInfo shape, not just a subset.
… network-aware path Leaves a pointer at the source of truth so a future ad-hoc Horizon call reaches for this instead of re-hardcoding a host the way useStellarAccount did (StellarSend#21).
Contributor
Author
|
please review all 4 checks has passed |
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
2 participants
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
Fixes #21.
src/hooks/useStellarAccount.tshardcodedhttps://horizon.stellar.org(mainnet) with no way to target testnet, unlikeWalletContext's network-awarefetchAccountFromHorizon(publicKey, network). For a testnet-only address, calling it would always 404 ("Account not found") even though the account genuinely exists on testnet — a confusing false negative.Per the issue's own suggested resolution, I checked for call sites before deciding between "fix in place" vs. "remove":
Zero call sites anywhere in the app — it's dead code. It also duplicated functionality that already exists, correctly, network-aware, in
useWallet's account state (backed byfetchAccountFromHorizon), and its localAccountInfoshape ({ address, balance, sequence }) was a narrower ad-hoc duplicate of the realAccountInfotype insrc/types(missing thresholds, flags, non-XLM balances).Since nothing imports it and a correct, network-aware equivalent already exists, this removes the hook entirely rather than threading network-awareness into unused code and maintaining two parallel account-fetching implementations.
The issue's "Testing strategy" section asked for a test asserting request-host selection by network. Since that logic lives correctly in
horizonUrl/fetchAccountFromHorizon(which had zero test coverage despite being exactly the code this whole issue is about), I added coverage there instead of testing the deleted hook: testnet/mainnet host selection, 404 and generic-error handling, and fullAccountInfofield mapping (thresholds/flags/multi-asset balances — the exact gapuseStellarAccount's narrower shape had).Test plan
grep -rn "useStellarAccount"confirms no remaining references after removalnpm run lint— cleannpx tsc --noEmit— cleannpx vitest run— 66/66 passing (7 new tests insrc/lib/api.test.ts)npm run build— succeeds