Initialize the Next.js client before handling the OAuth callback

[UdeshAthukorala]

Purpose

The Next.js quickstart's E2E tests fail intermittently at the second sign-in of a test: the browser lands on /?code=…, the page stays signed out, and the console shows [ThunderIDClientProvider] An error occurred while signing in: ThunderID client is not initialized. Seen on #112, #115 and the nightly run on main.

Approach

handleOAuthCallbackAction is the one server action that gives up when the client singleton in its module context is not initialized. Every other path (ThunderIDNextClient.ensureInitialized, used by the other actions) first initializes from the environment. In next dev, compiling another route between two sign-ins (the test visits /account in between) can hand the callback action a fresh, uninitialized module instance, so the code exchange never runs.

The action now initializes from the environment when needed, and only reports "not initialized" when that fails too. No behaviour change for a context that is already initialized.

Traced from the Playwright artifact of the failed run on #115: the callback action's response was followed by the dev overlay fetching stack frames for that error, and the test's own third sign-in in its finally block succeeded, which is the pattern of a per-context initialization gap rather than a ThunderID or credential problem.

Tests: three unit tests for the action (initializes when the context is not, does not re-initialize when it is, and fails cleanly when initialization fails). pnpm build, pnpm format:check and the Next.js unit tests pass.

Related Issues

• N/A

Related PRs

• Fix sharp and shell-quote audit advisories #115, whose E2E check hit this flake.

Checklist

• Followed the contribution guidelines.
• Manual test round performed and verified.
• Documentation provided. (Add links if there are any)
• Tests provided. (Add links if there are any)
  • Unit Tests
  • Integration Tests
• Breaking changes. (Fill if applicable)
  • Breaking changes section filled.
  • breaking change label added.
• Cross-SDK parity. Exactly one of parity/prs-raised or parity/prs-not-needed added.
  • If parity/prs-raised, the port links are posted as a reply on the parity check's comment.

SDK parity

• A fix confined to the Next.js SDK's own initialization; nothing reaches another SDK. parity/prs-not-needed.

Security checks

• Followed secure coding standards.
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Repository: thunder-id/javascript-sdks/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 31821e37-2ea3-4418-b060-ef02525b0dbd

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔀 Cross-SDK feature parity, no ports needed

This pull request is labelled parity/prs-not-needed: nothing here has to ship in the other ThunderID SDKs. If that changes, swap the label for parity/prs-raised.