fix: unlock no longer reports success over a lit-but-locked lock screen - #8
Merged
Conversation
unlock()'s "lit and no pad, so the phone was just asleep and is now usable" shortcut assumed a lit screen means unlocked. A priority notification keeps the lock screen LIT while still locked, so when the wake swipe failed to raise the pad (the ~16s wake-transition hang, after which the notification-lit screen never darkens to trigger the dark-screen retry) the shortcut returned success over a phone still on its lock screen — Wes's "runs ~20s then nothing happens". Add _on_lock_screen(tree), reading the CoverSheet markers already in the tree pad_appears fetched (SBCoverSheetWindow / "Swipe up to unlock" / "Locked"). The two lit-and-no-pad return branches now also require NOT being on the lock screen; a lit lock screen falls through to the second wake+swipe (which typically raises the pad) and, if the pad still never comes, raises an honest error naming the notification instead of lying success. Same lying-success class as the dark-screen silent return fixed 2026-08-13. Verified live: a locked phone unlocks to the home screen, no false early return. Three new tests, each confirmed red without the fix; full suite 470 green. The ~35s unlock latency (the pre-existing wake-transition hang, ~50% regardless of session freshness per 12 on-device trials) is out of scope. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WdcGc3QPjNzST7GCXZcc3S
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Problem
The viewer's Unlock button, with a priority notification on the lock screen, ran ~20s showing "Unlocking…" then did nothing — the phone stayed locked but the button reported done (Wes, 2026-08-20).
Root cause
unlock()had a shortcut: after the wake+swipe, if no passcode pad appeared but the screen was lit (>= _LIT_SCREEN_BYTES), it returned declaring success, on the theory "lit + no pad = phone was merely asleep and the swipe reached the home screen."A priority notification keeps the lock screen lit while still locked. When the wake swipe failed to raise the pad (the documented ~16s wake-transition hang, after which the notification-lit screen never darkens to trigger the dark-screen retry), that shortcut fired and returned
{ok: true}over a phone still on its lock screen. Without a notification the screen re-sleeps to dark between reads, so the code took the correct retry path and eventually unlocked — which is why it only broke with a notification.Fix
_on_lock_screen(tree)reads the CoverSheet markers already present in the treepad_appearsfetched (SBCoverSheetWindow, "Swipe up to unlock", "Locked"). The two "lit and no pad → return usable" branches now also require not being on the lock screen. A lit lock screen falls through to the second wake+swipe (which typically raises the pad and unlocks); if the pad still never comes, it raises an honest error naming the notification instead of lying success. Same lying-success class as the dark-screen silent return fixed 2026-08-13.Verification
docs/ERRORS.md.Out of scope (pre-existing)
The ~16s first-gesture-after-wake hang still costs the unlock ~35s end-to-end. 12 on-device session-ordering trials (2026-08-20) show it fires ~50% of the time regardless of session freshness, so the 2026-08-14 mint-up-front does not reliably avoid it — a WDA wake-transition heavy tail, same class as the TikTok wedge. Left alone deliberately.
🤖 Generated with Claude Code