Skip to content

fix(freighter): readFreighterConnection returns null when getAddress … - #334

Merged
Valreb001 merged 1 commit into
Tx-wats:mainfrom
Ike-Nathan:main
Oct 23, 2026
Merged

Valreb001 merged 1 commit into
Tx-wats:mainfrom
Ike-Nathan:main

Conversation

@Ike-Nathan

Copy link
Copy Markdown
Contributor

Problem

readFreighterConnection() is documented to return null when the extension isn't reachable. But await withTimeout(getAddress()) was outside any try. When the extension was slow or locked, the call rejected with FreighterUnavailableError, and callers such as useWallet and WalletStatusBadge caught it and showed "disconnected" instead of "unavailable".

Fix

  • getAddress is now wrapped in a try. A timeout or rejection returns null, the same as the existing isConnected probe failure.
  • A locked wallet still behaves as before: when getAddress answers with an error, the function returns { publicKey: null, ... }.
  • The diff is limited to this fix (10 lines in lib/freighter.ts).

Tests

New __tests__/readFreighterConnection.test.ts:

  • getAddress never settles (fake timers past the 2.5 s probe timeout) → null
  • getAddress rejects → null
  • getAddress answers with an error (locked wallet) → publicKey: null
  • happy path → address and network

The first two fail without the fix. On the rest of the unit suite there are no new failures: main already has 43 failing tests (the ContractsPage, ContractDetail and FreighterConnect suites, among others), and they fail the same way before and after this change.

Closes #185

…times out

readFreighterConnection is documented to return null when the extension
is not reachable, but `await withTimeout(getAddress())` sat outside any
try. A slow or locked extension made it reject with
FreighterUnavailableError, and callers such as useWallet and
WalletStatusBadge fell into their catch and showed "disconnected"
instead of "unavailable".

The getAddress call is now wrapped: a timeout or rejection returns null,
the same as a failed isConnected probe. A locked wallet (getAddress
answers with an error) still reports publicKey: null.

New __tests__/readFreighterConnection.test.ts covers getAddress never
settling (fake timers past the 2.5 s probe timeout), rejecting, answering
with an error, and succeeding. The first two fail without this fix.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@drips-wave

drips-wave Bot commented Oct 22, 2026

Copy link
Copy Markdown

@Ike-Nathan Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

@Valreb001
Valreb001 merged commit c4b857e into Tx-wats:main Oct 23, 2026
0 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

readFreighterConnection Throws When getAddress Times Out

2 participants