feat: with-walletconnect example (registerProvider reference integration) - #257
Conversation
…1193 path A WalletConnect provider is constructed, not injected, so wallet discovery can never see it - the exact gap getformo/sdk#360/#364 closed in SDK 1.38.0. This example is the API's reference integration: one FormoAnalytics.init, one EthereumProvider.init, and the one line that matters between them - formo.registerProvider(provider). - Plain Vite + React + TS, deliberately NO wagmi: wagmi apps never need this API (their WalletConnect sessions are already tracked and registerProvider refuses there to prevent double-reporting), and the README says so. - Sepolia pinned; the transaction button sends 0 ETH to yourself. - The UI surfaces what the capture sees: whether registration was accepted, and the wallet BEHIND the transport from the session's peer metadata - the Ledger Live attribution the whole P-2403 story is about. - Verified against a packed tarball of the sdk#364 branch: builds clean, and tsc proves the real EthereumProvider type satisfies registerProvider's signature. - Wired into the build matrix (path filter + entry), the compatibility sweep's EIP-1193 list, and the e2e install loop. Blocked on the 1.38.0 release: the pin is ^1.38.0 and the lockfile is deliberately absent until the package exists on npm - added in the routine release bump. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Dependency limit exceeded — report not shown. This pull request scan exceeded the 10,000-dependency limit applied to this scan, so the results are incomplete and may be inaccurate. To avoid reporting false positives, Socket has not posted a report. Upgrade your plan to raise the dependency limit and get complete reports, or view the partial scan in the dashboard. Socket is always free for open source. If this is a non-commercial open source project, contact us to request a free Team account. |
This comment has been minimized.
This comment has been minimized.
Live pairing showed two demo-level truths: the provider does not reliably emit connect on QR approval, and provider.accounts can be EMPTY on a live session while the namespaces hold the account. The UI now re-syncs after every action plus a slow poll, falls back to namespace-parsed accounts, and the connect button reports accounts, namespaces, chain, and peer verbatim so the person testing can see what the wallet actually approved. The same namespaces fallback is now in the SDK's adoption path (sdk#364), where it matters for real. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codex review, two majors, both mine: the paths-filter insertion STOLE with-react's workflow-file matcher into the new block (workflow changes stopped rebuilding with-react), and every wired job would fail anyway - not just for the missing lockfile the reviewer flagged, but because ^1.38.0 does not exist on npm yet, so no install flag can save it. with-react's matcher is restored and ALL with-walletconnect wiring (paths-filter, build matrix, e2e install loop, sweep list) moves to the post-release commit that adds the lockfile, where it can actually pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
@codex review |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 10 files
You’re at about 90% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7e8ca29245
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return () => { | ||
| cancelled = true; | ||
| formoRef.current?.cleanup?.(); | ||
| }; |
There was a problem hiding this comment.
When the component unmounts or Vite hot-reloads it, this cleanup leaves the 1.5-second interval and all five provider event handlers active. They retain syncSession and continue invoking state setters, and each remount adds another poll/listener set. Keep the interval and handler disposers in effect scope and call clearInterval plus provider.off/removeListener here.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in cce5418 together with the sibling comment: interval cleared and provider.removeListener for each of the five events in the effect cleanup.
| const ns = (provider.session?.namespaces?.eip155?.accounts ?? []) | ||
| .map((a: string) => a.split(":")[2]) | ||
| .filter(Boolean); |
There was a problem hiding this comment.
When provider.accounts is empty and the approved session contains both the required Sepolia chain and optional mainnet, this fallback discards each CAIP-10 account's chain component and uses whichever namespace entry happens to come first. WalletConnect permits different accounts per chain, so address can belong to a chain other than provider.chainId, causing signing or eth_sendTransaction to be rejected for an unauthorized from account. Filter namespace entries by the active chain before extracting the address.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Valid, fixed in cce5418: the fallback filters CAIP-10 entries by the ACTIVE chain (eip155::) first and only then falls back to any eip155 entry, so a per-chain-account session cannot select an unauthorized from.
Review comments on the demo, all valid: unmount and HMR leaked the 1.5s poll and five provider listeners (each remount stacked another live set), and the namespace fallback took whichever eip155 entry came first even though a session can authorize different accounts per chain. The effect now disposes its poll and listeners, and the fallback prefers entries for the ACTIVE chain before any eip155 entry. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The example resolves and builds against the published package; the paths-filter (with-react's workflow matcher intact this time), build matrix, e2e install loop, and sweep list all gain the example. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aikido flagged ten advisories (one high) against the axios 1.16.0 that @WalletConnect's tree pulls in. Overridden to 1.20.0, with the release line excluded from the age gate as prior remediations in this file did. Audit clean at the high gate; example builds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1 participant
Reference integration for
registerProvider, shipping in SDK 1.38.0 via getformo/sdk#364. Draft until 1.38.0 is on npm - the pin is^1.38.0and the lockfile is deliberately absent until then.What it shows
The exact gap P-2403 reported: a WalletConnect provider is constructed, not injected, so discovery can never see it. The fix is one line:
@walletconnect/ethereum-provider.tscproves the realEthereumProvidertype satisfiesregisterProvider's signature.To land after the 1.38.0 release
pnpm installinwith-walletconnectto generate the lockfile, commit it.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.