Persist the ID before you verify it: how a YouTube stage went blind to five live videos

Persist the identifier the instant the remote system hands it over. The upload stage broke that rule by one position: the local write was the fourth of four steps, sitting behind a verification call that re-queries the video through `videos.list` once the transfer finishes ^[1][2]. Verification earns its place in the flow, because the API can report success at the transport layer while the platform does something to the video that nobody asked for ^[3]. It is simply the wrong thing to stand between an irreversible act and the record of it. By the time that call can throw, the PUT has already produced a real video with a real ID ^[5], and an exception out of it takes the record with it. Not into an error state, out of existence ^[4].

From there the guard does exactly what it was written to do. It answers "have I uploaded this?" by testing whether `upload.json` exists, so the absence of the file reads as the absence of the video, and the next invocation performs a second complete upload rather than a retry ^[6]. The docstring said retries do not create duplicates, and that was true of the low-level file-PUT function, which reuses the same resumable session URI when the transfer stumbles ^[7]. Re-running the whole command from outside is a different code path that goes through the guard, and none of the inner safety reaches it ^[8].

The arithmetic is what makes this more than a near miss. Five episodes had already been published through an MCP tool that never wrote `upload.json` ^[9], and a single run of the new command pointed at any of them would have found no record and duplicated it ^[10]. That is five guaranteed duplicates available before the new stage had failed even once ^[1]. The guard's logic was correct throughout. The assumption underneath it, that `upload.json` is a complete list of what exists on the channel, was never true.

The test suite was green the entire time, including a case asserting that verification throws when it detects a demotion ^[11]. What no test asked was what remained on disk after that throw ^[12]. Assertions get pointed at return values and exception types because those are the cheap things to name; residual state has no natural owner in that style of test, which is where this class of bug lives.

The repair moves the checkpoint rather than the check: the record is written as soon as the video ID comes back, carrying `verified: false`, and gets promoted to `verified: true` if the follow-up query agrees ^[13]. That shortens the unrecorded window from "the whole verification round trip" to "the gap between receiving an ID and writing a small JSON file" ^[2], and it gives the guard something better than a boolean, with `--force` for a deliberate second copy and a `verified: false` record meaning resume verification against the ID already on disk ^[14]. The account does not say how the five earlier videos acquire records ^[15], and until they do, the new three-branch guard is still reading an incomplete ledger.