We latched the meeting to the microphone.
Window titles told us which call you were in — right up until you switched tabs. Then two machines quietly recorded the same conversation.
Five people join a call. Each of their laptops notices a meeting is happening. If every laptop records, you get five copies of the same hour, five transcripts to reconcile, and five times the storage — so the machines have to agree on which one of them is recording. One call, one recorder, one transcript.
Which requires answering a question that turns out to be much harder than it sounds: are these five people in the same call?
Almost nothing, and it got worse over time
The obvious signal is the window title. We audited every conferencing app our members actually use:
| App | Meeting id in the window title? |
|---|---|
| Google Meet (browser) | Yes — Meet – abc-defg-hij |
| Zoom (desktop) | No. Removed in April 2020, deliberately |
| Zoom (web) | No — the id is in the URL, not the title |
| Microsoft Teams | No. At best a meeting subject |
| Webex | No — topic only |
| Slack huddles | No public id; the pop-out is not a normal window |
| Discord | Title tracks the channel you are reading, not the call you are in |
Zoom's is the interesting row. They removed the meeting id from the title in April 2020, on purpose, because ids were leaking through screenshots people shared publicly. That is a good security decision by Zoom and it permanently deleted the signal we would have wanted.
So title-based grouping only ever worked for one product on that list. Our Zoom pattern has, in practice, never matched a real call — which is safe, because the fallback is everyone recording their own copy, but it means the largest slice of real usage got no deduplication at all.
Then we found something worse than a signal that rarely fires: a signal that stops firing halfway through.
A browser window's title is only ever its active tab's title. Switch from the Meet tab to the document you are discussing — the entirely normal thing to do in a meeting — and the meeting code vanishes from every window title on the machine, for the rest of the call. On macOS it also vanishes if you minimise the window or move it to another Space.
That would have been survivable if detection only decided labels. It didn't. The recorder held a lease renewed by a heartbeat, and the heartbeat only ran while the call was identified. So:
- You switch tabs. Identification stops.
- The heartbeat stops renewing, while the recording keeps running.
- The server concludes that machine has crashed and promotes a standby.
- Two machines are now recording the same conversation.
The mechanism built to prevent duplicate recordings became the thing causing them. Five confirmed failures before we understood the pattern.
Losing sight of the call did not stop the recording. It stopped the recorder from being able to say it was still there.
The fix has two halves, and the second is the one we would have missed if we had stopped at the first.
Latch the identity. A title tells you which call — once. It is terrible at telling you whether you are still in it. Something else is very good at that: whether the microphone is in use. It is one boolean, it needs no permission to read, and it stays true for exactly as long as you are in the call. So the identity a title established is held for as long as the mic is live, plus a two-minute grace after it goes quiet, because muting sometimes releases the device.
Anchor the heartbeat to the recording, not to detection. A live recording now pins its own call and renews its own lease. Detection can drop out entirely, for the whole call, and nothing happens — which is the actual bug fixed. Detection is never again allowed to cause the failure it exists to prevent.
There is an obvious next step here that we will not take, and writing down why is most of the value of this post.
The mic signal is so much more reliable than titles that it is tempting to promote it: if two people have live mics at the same time, group them. That would be a false-merge machine. Two people with their microphones on is not evidence they are in the same call — it is evidence that two people are talking, possibly to entirely different customers.
That is the general rule the whole subsystem is built on. Never merge two calls on anything less than equality of a real unique meeting id, or a human saying yes. Every signal is judged first on how badly it fails when it is wrong, and the system fails closed: no confident id means no grouping, which means everyone records their own copy — the mildly wasteful outcome, chosen deliberately over the unrecoverable one.
We would rather store five copies of a meeting than hand one of them to the wrong company.
Questions, corrections, or a war story of your own? Write to hello@worktrackhq.com — a person reads every message.
