Summary
AuthorizerVerifyOtp.tsx's WebOTP effect (added in #67, closing #66) includes webauthnLocked in its gate/dependency array specifically so a pending navigator.credentials.get({ otp: ... }) call gets aborted when a failed passkey-verify attempt locks the screen over to AuthorizerMfaLocked. That interaction has no automated test coverage, and can't get any with the tooling available today.
Why it can't be tested here
window.OTPCredential / the WebOTP API is only implemented in Chrome for Android - desktop Chromium (what Playwright's chromium project drives, and the only browser available in this environment/CI) never has it. The effect's feature-detection ('OTPCredential' in window) is false there, so the whole navigator.credentials.get() call - and therefore the abort path being tested - never executes at all. Any e2e test written against Playwright's Chromium would only be exercising the pre-existing webauthnLocked early-return render branch (if (webauthnLocked) return <AuthorizerMfaLocked />), which predates this change and is unrelated to the WebOTP effect specifically.
What was verified instead (see #67)
- Full existing MFA e2e suite (
mfa-totp.spec.ts, mfa-passkey.spec.ts, mfa-setup-skip.spec.ts - 6 specs total) passes against the merged build, exercising AuthorizerVerifyOtp through TOTP enrollment/verify/lockout, passkey primary login, and MFA setup/skip.
- Code-level trace:
webauthnLocked is a one-way useState(false) (only ever flips to true, never reset) already used in the pre-existing early-return; adding it to the new effect's gate/deps is a pure safety addition, not a change to existing render logic. tsc --noEmit and npm run build both clean.
- Not verified: an actual passkey-verify lockout occurring while a real WebOTP listener is active and observing it abort cleanly, end to end.
Suggested follow-up (when worth the investment)
- A real-device run (Android Chrome, physical or emulated) driving a passkey-verify failure while an SMS-OTP factor is also pending, if/when device-lab tooling (e.g. BrowserStack) is available to this project.
- Alternatively, a Chromium-only test that shims
window.OTPCredential/navigator.credentials.get via page.addInitScript purely to force the effect's feature-detection true, then drives the lockout and asserts the mocked promise's AbortSignal fires - this wouldn't prove real WebOTP behavior, but would at least give regression coverage for the abort wiring itself.
Context
Follow-up from #66 / #67, per the same "document the gap rather than fabricate a test around a mock that wouldn't prove anything" pattern #66 itself used.
Summary
AuthorizerVerifyOtp.tsx's WebOTP effect (added in #67, closing #66) includeswebauthnLockedin its gate/dependency array specifically so a pendingnavigator.credentials.get({ otp: ... })call gets aborted when a failed passkey-verify attempt locks the screen over toAuthorizerMfaLocked. That interaction has no automated test coverage, and can't get any with the tooling available today.Why it can't be tested here
window.OTPCredential/ the WebOTP API is only implemented in Chrome for Android - desktop Chromium (what Playwright'schromiumproject drives, and the only browser available in this environment/CI) never has it. The effect's feature-detection ('OTPCredential' in window) isfalsethere, so the wholenavigator.credentials.get()call - and therefore the abort path being tested - never executes at all. Any e2e test written against Playwright's Chromium would only be exercising the pre-existingwebauthnLockedearly-return render branch (if (webauthnLocked) return <AuthorizerMfaLocked />), which predates this change and is unrelated to the WebOTP effect specifically.What was verified instead (see #67)
mfa-totp.spec.ts,mfa-passkey.spec.ts,mfa-setup-skip.spec.ts- 6 specs total) passes against the merged build, exercisingAuthorizerVerifyOtpthrough TOTP enrollment/verify/lockout, passkey primary login, and MFA setup/skip.webauthnLockedis a one-wayuseState(false)(only ever flips totrue, never reset) already used in the pre-existing early-return; adding it to the new effect's gate/deps is a pure safety addition, not a change to existing render logic.tsc --noEmitandnpm run buildboth clean.Suggested follow-up (when worth the investment)
window.OTPCredential/navigator.credentials.getviapage.addInitScriptpurely to force the effect's feature-detection true, then drives the lockout and asserts the mocked promise'sAbortSignalfires - this wouldn't prove real WebOTP behavior, but would at least give regression coverage for the abort wiring itself.Context
Follow-up from #66 / #67, per the same "document the gap rather than fabricate a test around a mock that wouldn't prove anything" pattern #66 itself used.