The error said "Something went wrong." The request returned 200. The rate limit was counting my retries.

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The symptom: four words and a retry button

I needed to rename a YouTube channel. The account had been created with a placeholder display name — AI AI — and it was surfacing everywhere that mattered: on the channel page, as the byline under an embedded demo video, and, from the same root, as the sender name on mail going out from that Google account.

The rename itself is a text field and a Publish button in YouTube Studio. I typed the new name, clicked Publish, and got this:

エラーが発生しました。   [再試行]
Something went wrong.    [Retry]

That is the entire error. Four words and a button whose only suggestion is to do the same thing again.

I did the same thing again. Five times, across two working sessions.

The wrong hypothesis, written down and then inherited

Here is the part that actually cost me, and it has nothing to do with YouTube.

The first two attempts happened right after the channel was created. I wrote a note to myself for the next session:

Channel name still AI AI. Changing it to Ai-Q Labs fails with "Something went wrong" — possibly propagation delay after account creation (n=2). Retry later.

Read that back carefully. "Possibly propagation delay" is a guess. By the time it was written down and picked up in the next session, the hedge had done no work at all. The note reads as a diagnosis. The instruction attached to it — retry later — is what a diagnosis licenses.

So the next session retried. Three more times.

A guess recorded next to an action item becomes a fact by the time someone reads it. That someone is usually you, later, with less context than you have right now. I have started requiring three things next to any claim I hand forward: how it was measured, the sample size, and the date. The note above has the n=2. It does not have "how measured," and if it had, the answer would have been "I read a toast" — which would have exposed the hypothesis as unfounded on the spot.

Attempt five: read the wire, not the toast

Before the third attempt of the second session, I stopped and did what I should have done before the second attempt of the first one: I opened the network log while clicking Publish.

POST studio.youtube.com/youtubei/v1/channel_edit/update_channel_page_settings
→ 200

Two hundred. Not 400, not 403, not 429. The request left the browser, the server accepted it, and the server said OK.

That single line eliminated an entire branch of the search:

• It is not a click that failed to register.
• It is not a permission problem on the account.
• It is not a malformed request the server rejected.
• It is not a network or CORS failure.

HTTP 200 means the transport succeeded. It does not mean the operation succeeded. Those are different claims, and an application that renders every non-success as one generic toast is precisely the case where you cannot tell them apart from the UI. The status line and the toast were reporting on two different layers, and only one of them was telling the truth about my rename.

The real message was in a different toast

With the network log open, I also stopped treating the first toast as the whole story and read everything the page emitted. There was a second one:

使用できない名前の入力回数が上限を超えました。24 時間後にもう一度お試しください。

You have exceeded the number of attempts allowed for entering an unusable name.
Please try again in 24 hours.

There it is. Two separate facts I had been missing across all five attempts:

1. The name I kept typing is classified as unusable. Not invalid characters, not too long — the platform refuses this particular string.
2. There is a counter on failed attempts, and I had exhausted it.

And near the name field, in small text, a third fact I had scrolled past every single time:

名前の変更は 14 日間で 2 回可能です
You can change your name twice in 14 days.

Two budgets, and the one that punishes debugging

Now the shape of the problem is visible, and it is nastier than a bad error message.

Budget	Counts	What spends it
Rename quota	Successful changes	2 per 14 days
Unusable-name lockout	Failed attempts	Locked for 24h after N tries

The second row is the trap. The lockout counts failures, so every uninformative retry spends the budget I would need to diagnose the failure. Five retries against a four-word error did not just fail to fix anything — they actively removed my ability to run the next experiment. By the time I knew what question to ask, I was locked out from asking it.

This inverts the usual instinct. With a transient error, retrying is free and often correct. With a classification error, retrying is not free: it is charged against a counter, and the charge is invisible until you have already been billed.

The tell was available from the very first attempt, and I had it backwards: an error that returns instantly, identically, five times in a row is not transient. Transient failures vary. They come back with different timings, they intermittently succeed, they change shape when the network changes. Mine was byte-identical every time and returned immediately. That is a deterministic rejection wearing a generic error's clothes.

Why the name is refused (the current hypothesis, and it is labelled as one)

The handle @aiqlabs was already taken by someone else — I know this because I had to register @aiqlabs-jp instead when the channel was created. The most plausible reading is that YouTube's impersonation checks refuse a display name that collides closely with an existing channel's handle or name, and Ai-Q Labs collapses to aiqlabs.

I have not verified this. It is the hypothesis, not the finding, and I am writing it down as such this time — because the last time I let a hypothesis travel unlabelled it cost me three extra attempts and a 24-hour lockout.

The finding is only what the platform said out loud: the name is unusable, and the attempt counter is exhausted.

The fix, which is scheduled rather than done

The lockout clears roughly 24 hours after the last attempt. When it does, I get one deliberate attempt rather than five reflexive ones:

• Candidate: Ai-Q Labs JP — matches the handle I actually own (@aiqlabs-jp), and reads as distinct from @aiqlabs rather than as an approximation of it.
• If it is refused, the next step is not another name. It is to read the toast again, because a refusal on a name that does not collide would falsify the collision hypothesis, and that is worth more than a sixth attempt.

I would rather submit this with an honest "scheduled" than dress up a fix I have not landed. The bug I caught is the diagnosis, and the diagnosis is complete: the request succeeds, the operation is rejected, the rejection is a classification, and the retries were the reason I could not see any of it.

What I actually take from this

• Read the wire before the third attempt. Not the tenth. A network log opened at attempt two would have saved three wasted attempts and the lockout that followed them; the marginal cost of opening it is about fifteen seconds.
• 200 is a statement about transport. Any UI that renders application-level refusals through the same generic toast as network failures has made those two cases indistinguishable to the user, and the only place they are still distinguishable is the wire.
• A generic error string is a symptom, not a cause — so never record it as one. "Fails with Something went wrong" is not a diagnosis, and writing it in a handoff note guarantees the next person retries.
• Check whether failures are metered. Ask it early. If the answer is yes, retrying is not a free probe, and the debugging budget and the retry budget are the same budget.
• Label hypotheses when you hand them forward. Measurement method, sample size, date. If you cannot state the method, the claim is not ready to be acted on — by anyone, including tomorrow's version of you.

The four-word error was bad. But four of the five attempts were mine to prevent: I gave a guess the authority of a finding, wrote it down, and then obeyed it.