Josh Huang's Engineering Notes
The API That Doesn't Wait: A Race Condition in Plain Sight
An automation's two-factor login kept failing with 'input is empty' even when the correct code was submitted a second later — because a second later was already too late, and the actual fix was in the order of two API calls, not their content.
This article is also available in Traditional Chinese: 中文版 — same content, just a language difference.
Submitting a correct two-factor code to an automated login flow's HTTP API, immediately after triggering the login, failed consistently with a generic "input is empty" error — even though the code was right, submitted quickly, and the same exact sequence would sometimes work moments later on manual retry. The actual bug was a race condition hiding in plain sight: an assumption that the API would wait for input that it never actually waits for.
The obvious-looking approach, and why it failed
A self-hosted account-automation tool exposes an HTTP API with two relevant calls: one to trigger a login attempt for a given account, and one to submit a pending input value (a two-factor code, an emailed verification code, or a yes/no device-approval response) once the tool asks for one. The obviously-correct-looking sequence is: trigger the login, wait for it to ask for input, then submit the input it asked for. That sequence failed close to every time, with a log message amounting to "input is empty" — as if nothing had been submitted at all, despite a value clearly having been POSTed moments after triggering the attempt.
Unlock this article to keep reading, or subscribe for unlimited access to everything. See Pricing for details.