Two of my automated posts worked that night, and I could not have told you why

I drive a browser over the DevTools protocol to publish and to answer comments. Last night three comment submissions failed in the most annoying way available: the form was submitted, no error came back, no rate limit was mentioned, the text stayed sitting in the box, and nothing was published. Two other submissions the same night had worked perfectly. The interesting part is not the bug. It is that I could not have explained the two successes either. What I did instead of a fourth attempt I stopped, because I have a rule about this: piling up attempts has never once worked for me, and each retry on a publishing action risks posting the same thing twice. Instead I wrote down exactly one hypothesis, in a form that could be wrong: the comment form is not fully rendered until it has been focused, and the submit control does not exist before that. That is falsifiable in about thirty seconds, which is the only property that matters at four in the morning. The measurement Count the visible buttons inside the form, before and after a real mouse click in the text area. Before the click: zero. After the click: twelve, including Submit. So the button was not hidden, or disabled, or off screen. It did not exist. Every one of my failing runs had been writing text into a control that the page had not yet wired up, then asking a form with no submit path to submit itself. No error, because from the page's point of view nothing invalid had happened. The next attempt, with a real click first, published on the first try. The part that actually taught me something Both of my successful submissions that night had gone through a different code path, one that clicks a Reply control before writing. That click was unfolding the form. I had written that step for a completely different reason, and I believed the success came from the form submission afterwards. So my working code contained a necessary step that I did not know was necessary. It worked, I could not explain why, and I did not notice that I could not explain why, because working code does not prompt you for an explanation. A success you cannot explain is not a reproducible success. It is a coincidence that has not yet been disturbed. The day I had simplified that function, removed the click that looked redundant, and kept the submission that looked essential, it would have broken and I would have had no idea what I had removed. Three things I now do differently A real click is not the same as focus. Calling focus on an element, or assigning to its value and dispatching input events, gets you past a lot of checks. It does not necessarily run whatever the application does on genuine pointer interaction. When a form seems inert, the first question is now whether it has ever been touched the way a person would touch it. The interface is not the verdict. I had a check that read whether the text box emptied after submitting. It reported failure on a comment that had in fact published, because the box does not always clear on success. A false failure is worse than no check: it makes you resend, and resending a comment is how you end up posting twice. The verdict now comes from the platform's public API, which returns the thread and its structure, and I read my own text back out of it. When something works, ask which step did the work. Not always, and not for everything. But for anything that publishes, once, deliberately: if I removed this line, would I be able to predict what happens. If the answer is no, the code is holding knowledge I do not have. What I still do not know The threaded variant of the same script still fails on a thread that already contains a reply. I have a plausible explanation, which is that the unfolded box in that case is the main one my selector explicitly skips. That is a hypothesis, not a measurement, and I am writing it down as a hypothesis rather than treating it as an answer, because the whole point of the night was that a comfortable explanation is not evidence. Disclosure I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year and there is a free tier. The automation above exists to run its distribution, and this post is one of the nights where the tooling taught me more than the distribution did. You can find it at blueticks.io. If you automate anything that publishes, the cheap exercise is to take the function that works and try to say, out loud, which line is load bearing. Mine had one I would have deleted. Top comments (0)