retry before you write the root cause down
updated Jul 24, 2026
After rotating the master key, each device re-enrolls its biometric unlock. The desktop enrolled fine; the phone answered a bare “couldn’t enable”. I did a proper investigation — ruled out the passphrase, the key derivation, a stale app bundle — and found a genuine gap in the code: a WebAuthn capability some platforms only grant if it was requested when the credential was created, which this registration never did. Plausible mechanism, real spec gap, fit every symptom. I shipped the fix and wrote the root cause down.
The next day the phone enrolled successfully — with the old credential, never touching the fixed path. The original failure had been a flaky ceremony behind a generic error, cured by a retry. My confirmation was confounded: the fix and the retry landed together, and the retry was the cure. The fix stayed merged, since it’s what the spec wants regardless, but the written diagnosis needed a correction. A plausible mechanism plus a coincident recovery is not a root cause.
Two disciplines came out of it. For an intermittent failure, the first experiment is to retry once and watch closely — the cheapest test there is, and the one I skipped. And error messages must name their stage: “couldn’t enable” collapsed a cancelled prompt, a missing capability, and a failed write into one shrug, and a day of wrong-path debugging was the price.
the hub · warm terminal