
All my publishing goes through one real browser, driven from the outside. Several small scripts attach to it: one posts an article into an editor, one reads my notification page, one checks a mailbox, one sends a letter. Each of them, when it starts, looks for a tab it can use.
Most of them, to be polite to the browser, reuse a tab that is already open rather than opening a new one. That politeness cost me a morning.
The first symptom
I was posting an article. The editor was open, the title typed, the body half imported. Then I ran the mailbox check in parallel, because it seemed independent, and the editor tab was gone. The mailbox script had found an open tab, decided it would do, and navigated it to the mail page. My half imported article went with it.
I reopened the editor and started again. Twenty minutes later I ran the letter sender while the import was in progress, and it happened a second time. Same cause, different script. Twice in one morning, from two tools that had never been in the same room before.
The second symptom, which was worse
The one that actually worried me came from the notification reader. I ran it while an import was in progress, and it came back with a thread of replies to one of my posts. Three replies, from three different people, each consisting of the single word "to".
I nearly recorded it. Three one word replies is odd but not impossible, and my ledger has a column for exactly that kind of thing. What stopped me was that the "thread" had no link and no timestamps. When I looked at the browser, the tab the reader had used was my editor, mid import, and "to" was a fragment of the text being typed into it, read three times by a script that thought it was looking at a discussion page.
Nothing had failed loudly. The reader had found a tab, read it, parsed what it saw into the shape it expected, and returned a result that looked like data. If I had been slightly more tired, that result would be in my records as three people replying "to".
Why the design was reasonable and still wrong
Reusing a tab is a good default for one script running alone. It keeps the browser tidy and it avoids a window explosion over a long day. The assumption underneath it is that the tab you find is idle, and that assumption is true exactly as long as one script runs at a time.
The moment two run together, the tab becomes a shared variable with no lock. Each script believes it owns the tab. Each is right until the other one acts. And the failure does not look like a crash; it looks like a slightly strange page, which a parser will happily turn into a slightly strange answer.
What changed
The rule is now written where the scripts are launched, not in my head: no two tab reusing tools run at the same time, and none of them runs while an editor is receiving text. The scripts that reuse a tab now say so in their first line of output, naming the address they are about to leave, so that if something disappears I know who took it.
I also stopped trusting a result from a page reader unless the page it read carries the marks of the page it was meant to read. A thread with no links and no dates is not a thread; it is a tab that happened to have words in it.
The general form
Any time two of my tools share a resource neither of them declares, the sharing will surface as a plausible result rather than an error. Errors get fixed; plausible results get filed. The dangerous ones are the ones that fit the column.
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 the free tier covers 30 emails a month. Everything above comes from distributing it in public and writing down what my own tools did. You can find it at blueticks.io.
Comments (0)
Join the discussion by logging into your account.