fix(web): guard invite-settings activate button against double-click

[SquabbyZ]

Fixes #38410

Summary

The /signin/invite-settings activate button calls handleActivate() which awaits activateMember(...). Until the call resolves the button stays enabled, so a fast user (or an accidental Enter keypress in the Name input ??the input already wires Enter to handleActivate via onKeyDown) can submit the request multiple times. The backend may issue duplicate workspace-membership rows or, worse, race the setLocaleOnClient + router.replace side effects.

This change adds an isActivating state, sets it to true at the top of handleActivate(), resets it in the catch block (alongside the existing recheck()), and binds it to the activate button via loading={isActivating} disabled={isActivating} so the button visually deactivates and ignores further clicks while the request is in flight.

Changes

• web/app/signin/invite-settings/page.tsx:
  • Add const [isActivating, setIsActivating] = useState(false).
  • In handleActivate(): setIsActivating(true) before the await activateMember(...) call; setIsActivating(false) in the catch block alongside recheck().
  • On the activate <Button>: add loading={isActivating} disabled={isActivating}.
  • Update useCallback deps to include isActivating for react-hooks/exhaustive-deps.

The pre-existing if (!checkRes) return <Loading /> guard is preserved verbatim (it still works because useInvitationCheck returns { data: undefined, isPending: true } until the first response arrives ??i.e. checkRes is undefined, not null).

Diff stat

web/app/signin/invite-settings/page.tsx | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

Test plan

• Manual: open /signin/invite-settings?invite_token=... with a valid token ??fill name ??click activate twice quickly ??confirm only one POST /activate request fires (DevTools network panel).
• Manual: click activate ??before it resolves, press Enter in the Name input ??confirm button is disabled, no second request.
• Manual: simulate a backend 500 ??confirm isActivating resets and the button re-enables for retry.
• pnpm lint and pnpm type-check clean.

Risk / behavior preservation

• The happy path (res.result === 'success' ??router.replace) is unchanged.
• The catch block still calls recheck() to refresh the invitation validity check; we just additionally reset isActivating so the user can retry.
• No backend, schema, i18n, or migration changes.

Related

• Discovered by peaks-loop session 2026-07-02-session-95565c during a project scan on 2026-07-02.
• Sister fixes in this sign-in-flow series: PR fix(api): restore missing-document warning in document_indexing_task #38334 (backend indexing), PR fix(web): surface SSO login errors to the user #38335 (SSO errors), PR fix(web): surface check-code email login errors to the user #38336 (check-code errors).

Automation

Generated via peaks-loop (full-auto mode). Red-line scope was limited to web/app/signin/invite-settings/page.tsx. Commit message includes the peaks-loop provenance line for traceability.

?? Generated with Claude Code via peaks-loop

[crazywoola]

Thanks for the contribution. Before we review this PR, please open an issue first to describe the problem, expected behavior, and proposed approach, then link that issue here. This helps us confirm the scope and align on the fix before moving forward.

[SquabbyZ]

@crazywoola Thanks for the guidance. Opened issue #38410 describing the invite-settings "Activate" button double-click / Enter-key bug, the proposed isActivating state guard, and the risk analysis (happy path unchanged). PR description now links the issue via Fixes #38410. Ready for re-review.