Skip to content

Conversation

@godsflaw
Copy link
Contributor

Previously, dialog accounts were cleared whenever a request came in without an explicit account field (e.g. wallet_sendCalls without from). This caused accounts to be incorrectly cleared on normal requests, requiring re-authentication.

Now accounts are only cleared when the request method is explicitly wallet_disconnect, preserving account state through requests that simply don't specify a from address.

Fixes regression from #1009

NOTE: The original condition !account && connectedAccount?.address used the account parameter from onDialogRequest, which is derived from request fields like from. This was intended to detect "user no longer has an account," but it conflated "request doesn't specify an account" with "user disconnected." The fix makes this distinction explicit by checking the request method.

However, there may be edge cases where disconnection occurs and we don't detect it:

  • If the parent app's Porto instance loses its account state unexpectedly (e.g., localStorage cleared, storage corruption, or a bug) without calling wallet_disconnect, the dialog would retain stale account state.
  • In such cases, the dialog and parent would be out of sync until the user explicitly disconnects or the dialog is reloaded.

Previously, dialog accounts were cleared whenever a request came in without
an explicit `account` field (e.g. wallet_sendCalls without `from`). This
caused accounts to be incorrectly cleared on normal requests, requiring
re-authentication.

Now accounts are only cleared when the request method is explicitly
`wallet_disconnect`, preserving account state through requests that simply
don't specify a `from` address.

Fixes regression from ithacaxyz#1009
@changeset-bot
Copy link

changeset-bot bot commented Nov 26, 2025

⚠️ No Changeset found

Latest commit: 7def4a5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@vercel
Copy link

vercel bot commented Nov 26, 2025

Someone is attempting to deploy a commit to the Ithaca Team on Vercel.

A member of the Team first needs to authorize it.

@pkg-pr-new
Copy link

pkg-pr-new bot commented Nov 26, 2025

Open in StackBlitz

npm i https://pkg.pr.new/porto@1040

commit: 7def4a5


// Clear accounts on dialog init. If the parent has a connected account,
// it will be synced via when the first request comes in (requireAccountSync).
porto._internal.store.setState((x) => ({ ...x, accounts: [] }))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change regresses account persistence for per-action Porto initialization

Our use case

We don't initialize Porto on page load because the library is substantial and most users visiting a page won't need wallet functionality. Instead, we initialize Porto on-demand when the user clicks a button that requires wallet interaction (e.g., "Connect Wallet" or "Send Transaction").

This means:

  1. User clicks "Connect Wallet" → Porto initializes, dialog opens, user connects
  2. User clicks "Send Transaction" → Porto dialog re-initializes for this action
  3. The connected account from step 1 should persist and be available for step 2

The regression

Unconditionally clearing accounts in onInitialized breaks this flow:

  1. User connects → account stored ✓
  2. User clicks another action → dialog re-initializes
  3. onInitialized fires → accounts cleared
  4. wallet_sendCalls arrives without from field (relies on connected account)
  5. requireAccountSync doesn't trigger (because account is undefined in the request)
  6. No account available → request fails

The architectural mismatch

This change assumes onInitialized = "app startup" where no prior state should exist. In our architecture, onInitialized = "dialog opened for an action" and prior state (the connected account) should persist across these initializations.

The parent context maintains the account state, and requireAccountSync exists to sync when needed. But clearing accounts on every init breaks this before the sync logic even runs.

Resolution

I guess I'm not sure what to suggest as a resolution. Just revering this change works for us, but you're clearly aiming for a behavior by clearing on init. If we have to preserve that behavior, perhaps we add an option, or change this to sync from the parent on init? Not sure.

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.

2 participants