[Bug] Resetting a key binding does not restore the chord that was removed

[Bidthedog]

Labels

• At least one area:* label added (area:preferences, area:infra).

What happened (observed outcome)

Resetting a modified key binding did not restore the chord that had been removed.

zoom.in ships with three chords:

['Ctrl+=', 'Ctrl++', 'Ctrl+WheelUp']      packages/core/src/config/keybindings.ts:238

preferences-reset.e2e.ts:265 ("US1: a key binding shows a reset icon only once overridden, and
resetting it restores the shipped chords") removes chord 0 (Ctrl+=), confirms the file drops to
two chords, then clicks the row's Reset control and polls for the full shipped set to come back.

It never came back. The poll ran its whole 15s budget against a value that was stably wrong:

- Expected  - 1
+ Received  + 0

  Array [
-   "Ctrl+=",
    "Ctrl++",
    "Ctrl+WheelUp",
  ]

Call Log:
- Timeout 15000ms exceeded while waiting on the predicate
  at packages/ui/tests/e2e/preferences-reset.e2e.ts:313

A 15s poll that never sees the value change is not a slow write. The reset either did not run or
ran and produced the wrong result — this is not the shape of a timing race, where the value arrives
late rather than not at all.

What you expected (intended outcome)

Reset restores the full shipped chord set for that action, which is what the control promises and
what the surrounding assertions (US1/AC4) are written against — "the FULL shipped chord set comes
back, not just the removed chord".

Steps to reproduce

Observed once, in a full local npm run test:e2e (parallel tier at 6 workers, then serial tier
at 1, retries off). It has not been reproduced in isolation — no attempt was made to stress the
spec on its own, so the frequency is unknown.

1. npm run test:e2e on a clean checkout.
2. Serial tier reaches preferences-reset.e2e.ts:265.
3. It fails at :313 with the diff above.

Doing it by hand: open Preferences → Key Bindings, remove the first chord from Zoom in, then
click that row's Reset control and check whether Ctrl+= returns.

Environment

• OS / version: Windows 11
• throng branch or commit: master @ 3399b1b2, measured in a clean worktree with no product diff
• Elevated (admin) run? no

Evidence

The run it was seen in was otherwise clean: parallel tier 205 passed / 0 failed, serial tier
346 passed / 1 failed / 6 did not run (18.4 min). The six that did not run are the rest of
preferences-reset.e2e.ts, skipped because the file shares one app in serial mode.

That whole run was made on an unmodified checkout, so nothing local caused it.

Why this is filed separately

#250 is closed and named a different assertion in this file (preferences-reset.e2e.ts:77,
reported there as cannot-reproduce). This is a different line with a different symptom — a wrong
value rather than a timing failure — so folding it into a closed issue would bury it.

Found while investigating #267 / #321 / #286; it is not one of those and is not a cross-tier
scheduling artifact.

Related to #250.

Maintainer agreement

• Agreed by maintainer. Contributor may proceed with a fix (full lifecycle unless trivially small).

[Bidthedog]

Correction: it is intermittent, not consistent

A second full npm run gate on the same machine ran this test green in 960ms:

ok 179 packages\ui\tests\e2e\preferences-reset.e2e.ts:265:1 › US1: a key binding shows a reset
   icon only once overridden, and resetting it restores the shipped chords @extended @prefs (960ms)

The issue as filed said the frequency was unknown; this is the first counter-observation, so:
seen failing once, passing once, both in full runs on the same machine within a few hours.

That changes the reading of the original evidence. The failing run took 14.7s against 960ms
here, and almost all of that difference is the 15s poll timing out — so the "stably wrong value"
framing in the body is right about what was observed but should not be read as "reset is
deterministically broken". Whatever it is, it happens sometimes.

Both observations were on unmodified master @ 3399b1b2, so nothing local is implicated either
way.

Worth knowing before anyone tries to fix it: it will not reproduce on demand from a single run, and
the cheap first step is a stress of that one spec (--repeat-each, --workers=1,
THRONG_E2E_RETRIES=0) to get a rate before touching anything.

[Bidthedog]

🤖 Claimed by a Claude Code session — work on this issue has started.

• Session: adf72ed7-1264-4b49
• Scope: gate-reliability group: the real keybinding-reset defect behind preferences-reset.e2e:265 — fixed first so the flake family can be diagnosed against a spec that is not also failing for a real reason

Another session should not start work here until a released or complete comment appears below.

[Bidthedog]

✅ Complete — the claimed work has landed; the claim is finished.

• Session: adf72ed7-1264-4b49
• PR: Two lost-work defects behind the preferences flake family (#333, #341) #348