Last week I wrote about Astra's cool ability to fix a 34 year old bug in a Windows binary. But, as so often happens, it was only after I'd published the article that I realised I'd asked the wrong question. Instead I should have asked: find and fix all the bugs you can in this app.
But it’s never too late - so I gave it a whirl. And would you know…
Another four bugs. All fixed by tweaking seven bytes.
In the past I sometimes came across an engineer who could do something similar - patch a few select bytes in an existing program to fix a bug. But they are a rare beast - this type of engineering is hard. Having this capability permanently on call is, well, wild. I was so impressed I got Claude to create a website with the details.
The other thing I’ve been dealing with this week is disk space. Or the lack of. It turns out that having hundreds of agents running 24/7 introduces new weaknesses - and disk space is one of them.
First Claude Code quite reasonably instructs agents to store temporary files in the OS temp directory. On macOS that gets cleared on a reboot. So far, so reasonable. But if you have a reliable OS that doesn’t need rebooted often (tick for macOS), and have lots of busy agents, it’s easy for temp to get into terabyte territory. Unintended consequences and all that.
Then there are tests. My emulator continues to grow more test cases, more test suites, more pinned golden screen-captures. We’re now at ~6GB. And until this week they lived in the main repo. But each worktree clones the main repo - so each worktree consumes 6GB. Multiple hundreds of worktrees are plausible - so suddenly another few terabytes disappears. Not something I expected.
But, really, these are a small price to pay for the vast volumes of testing that I can now get for, essentially, free.
The real world
Back in the real world, I found myself thinking about testing as I read the initial report into the recent UK ATC outage at the start of September.
The presentation from NATS seems to be “rare thing, these things happen, we failed safe so all was well.”
The information so far points at a race-condition bug, followed by a fairly disastrous recovery that made everything much worse.
The story goes like this: A manual request was made for a squawk code - the four-digit transponder identifier ATC uses to associate an aircraft with its flight plan. But while NATS' National Airspace System (NAS) was working on that request, a higher-priority message arrived. So it paused the squawk code operation, dealt with the urgent message, and then went back to working on the squawk code. Except that it didn’t properly restore the original state - and corrupted flight data.
So far so bad. But then it got a lot worse.
A little later the London Area Control (LAC) system hit the corrupt record, timed out and disconnected from NAS. That recovered and ~45s later was back to normal. It appears the operators noticed the disconnect - good. However they appear to have interpreted it as a hardware problem and so set off debugging a non-problem.
Meanwhile the corrupt record lived on and started to cause escalating damage with the link dropping more frequently. Things unravelled rapidly from there.
The recovery was messy, requiring lots of manual reconciliation. And taking many hours.
But, of course, this wasn’t the first time this happened. Back in August 2023 there was another rare edge condition bug which also caused disruption over several days.
And, ironically, as I was writing this there was another outage at Prestwick. It’s not going well for NATS.
What’s interesting is the insight these outages give into NATS’ engineering culture. I imagine the August 2023 outage was a wake-up call, but it seems it wasn’t sufficient.
First, even for old code, there is plenty that can be done. Detailed code review. Static analysis. Poking at edge conditions. Mutation testing, fuzz testing, property testing. Corruption detection. So, so many things to explore.
An ATC system feels quite practical to test - stand up multiple test systems and then load them up. Push them harder than the real-world. Explore the window conditions. Even before AI, cloud makes getting the resources required for this testing fairly straightforward.
But the bigger concern is observability. Or rather the apparent lack of it. Things will go wrong. And understanding what has gone wrong is key to recovering. Given the wild goose chase the engineers went on looking for a hardware problem it seems there is an observability problem. Either the system didn’t log why it disconnected. Or the operators didn’t trust it. Neither is good.
Then there is the "this was only a 1ms" window justification, as if somehow that makes it OK. A lot can happen in 1ms; the machine I’m using can execute tens of millions of instructions in that time…
Timing windows, however small, are not good things to have in software. Small does not equal ok. Especially for critical infrastructure. This passage is worrying; it is not consistent with resilient software engineering.
And finally there is the fail safe claim. No one died. This is good. But is it really OK for NATS to stop processing data and dump everything on what seems to be mostly manual processes? Such an approach opens up a whole host of poorly (if at all) tested workflows. The public messaging suggests they haven’t quite understood the requirements of service resilience.
And so?
It feels like there’s something wrong here. My emulator shouldn’t be better tested than our critical ATC infrastructure. And yet it feels like it might be.
Plus it’s not just our ATC infrastructure. I bet there are countless other systems just like the NATS system failing every day - but because they are commercial we never get to find out about their failures.
Technically there’s nothing stopping NATS - or other companies - significantly improving their testing. The politics, however, might be harder. Imagine if the Hugging Face swarm had been focussed on finding bugs in NATS’ software - what gems might it have found?
But can we sort the politics? Get the leadership in place who’ll ask the questions necessary to drive the changes in engineering culture?
I don’t know. But if we did then maybe this could be the last major ATC outage we have to endure…