e2e: diagnose and reduce flakiness in browser login TOTP handling - #1778
Draft
adombeck wants to merge 3 commits into
Draft
e2e: diagnose and reduce flakiness in browser login TOTP handling#1778adombeck wants to merge 3 commits into
adombeck wants to merge 3 commits into
Conversation
generate_totp() only returned the code string, discarding the time step and generation time it was derived from. Callers had no way to tell whether a code was rejected because it was stale (submitted too close to the end of its validity window) or because it was wrong from the start, which made flaky TOTP failures hard to diagnose. Introduce TOTPCode, a small dataclass carrying the code alongside its time step and generation timestamp, with helpers to compute its remaining validity and age. generate_totp() is kept as a thin wrapper around the new generate_totp_details() for existing callers. While here, bump the minimum validity a freshly generated code must have left from 5 to 10 seconds, giving more headroom to type it in and have the identity provider validate it before it expires. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Key events sent to the WebKit view are handled asynchronously, so there was no way to confirm that typed text actually reached the page before submitting it. A dropped or misdirected key event silently turned into a wrong TOTP code, indistinguishable from one rejected for other reasons. Add run_javascript_sync() to execute JavaScript in the page and block until it returns or times out, get_focused_input_value() to read the value of document.activeElement, and wait_for_focused_input_value() to poll until the field matches an expected value, since the typed text can lag behind the key events that produced it. After typing a TOTP code, read the focused input back and compare it to the expected value; retype once if it doesn't match before giving up. Also log the code, its time step and remaining validity when it is submitted, and log the same details when a code is rejected, so a stale code can be told apart from one that was wrong from the start. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
adombeck
added
the
e2e-tests
The release matrix shares one broker MFA account, but serializing each full e2e job unnecessarily multiplies the test duration. Acquire a broker-specific, lease-based R2 lock only while Browser.Login runs so other tests and brokers remain parallel. The lock is an experiment for an observed correlation, not a confirmed explanation or guaranteed fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
adombeck
force-pushed
the
1777-e2e-browser-login-test-flakily
branch
from
August 18, 2026 11:47
79cc5aa to
51636c9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tries to fix the e2e browser login test flakiness described in #1777. TOTP-based logins were intermittently failing with no way to tell whether a rejected code was actually wrong, stale, or never made it into the page at all.
See commit messages for details.