Live data from Hacker News

Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

flightglobal.com

261–270 of 311 posts

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#261
post #190

Earlier quoted context omitted.

That's not what an exception proving a rule means. It has a technical meaning: a sign that says "free parking on sundays" implies parking is not free as a rule. When used like this it just confuses a reader with rethoric. In this case netflix is just bad at live streaming, they clearly haven't done the necessary engineering work on it.

> That's not what an exception proving a rule means. It has a technical meaning: a sign that says "free parking on sundays" implies parking is not free as a rule. So the rule is "Free parking on Sundays", and the exception that proves it is "Free parking on Sundays"? That's a post-hoc (circular) argument that does not convince me at all. I read a different explanation of this phrase on HN recently: the "prove" in "ex…

The origin of the phrase is the aphorism that "all rules have an exception". So, when someone claims something is a rule and you find an exception, that's just the exception that proves it's a real rule. It's a joke, essentially, based on the common-sense meaning of the word "rule" (which is much less strict than the mathematical word "rule").

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#262

Earlier quoted context omitted.

That is "a" solution. Another solution that is very foreign to us in sweng, but is common practice in, say, aviation, is to have that fallback plan in a big thick book, and to have a light that says "Oh it's time to use the fallback plan", rather than require users to diagnose the issue and remember the fallback. This was one of the key ideas in the design of critical systems*: Instead of automating the execution of…

Isn't what you're proposing exactly what led to this being a major problem? The automated systems disabled themselves, so people had to use the manual way, which was much less efficient, and 1,500 flights had to be cancelled.

They are referring to air crew procedures, not ATC. WHen the crew of an aircraft encounter a failure that doesn't have a common simple response, they consult a procedure book. This is something professional crews are well acquainted with and used to. The problem in the article was with the air traffic control system. They did not have a proper failback procedure and it caused major disruptions.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#263

Earlier quoted context omitted.

Ah, chubby is a distributed lock service. Think “zookeeper” and you won’t be far off. https://static.googleusercontent.com/media/research.google.c... [pdf] Some random blog post: https://medium.com/coinmonks/chubby-a-centralized-lock-servi... You can run multiple copies/instances of chubby at the same time (like you could run two separate zookeepers). You usually run an odd number of them, typically 5. A group of chu…

Not trying to "challenge" your story, and its interesting anecdote in context. But if you have time to indulge me (and I'm not a real expert at distributed systems, which might be obvious) - Why would you have a distributed lock service that (if I read right) has multiple redundant processes that can tolerate failures... and then require clients tolerate outages? Isn't the purpose of this kind of architecture so that…

Because you want the failure modes to be graceful and recovery to be automatic.

When the foundation of a technology stack has a failure, there are two different axis of failure.

1. How well do things keep working without the root service? Does every service that can be provided without it still keep going?

2. How automatically does the system recover when the root service is restored? Do you need to bring down the entire system and restore it in a precise order of dependencies?

It's nice if your system can tolerate the missing service and keep chugging along, but it is essential that your system not deadlock on the root service disappearing and stay deadlocked after the service is restored. At best, that turns a downtime of minutes into a downtime of hours, as you carefully turn down every service and bring them back up in a carefully proscribed order. At worse, you discover that your system that hasn't gone down in three years has acquired circular dependencies among its services, and you need to devise new fixes and work-arounds to allow it to be brought back up at all.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#265

It's like déjà vu all over again, Yogi. Aug 2023: “UK air traffic woes caused by 'invalid flight plan data'” https://www.theregister.com/2023/08/30/uk_air_traffic_woes_i... -- (-11 down votes and counting)

The very first line of the article states that this is a retrospective of the August '23 incident, hence the downvotes.

[dead]

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#266
Unique IDs that are not really unique are the beginning of all evil, and there is a special place in hell for those that "recycle" GUIDs instead of generating new ones.

Having ambiguous names can likewise lead to disaster, as seen here, even if this incident had only mild consequences. (Having worked on place name ambiguity academically, I met people who flew to the wrong country due to city name ambiguity and more.)

At least artificial technical names/labels should be globally unambiguous.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#267
post #9

FYI: nm = nautical miles, not nanometers.

We all need to stop using abbreviations, in my opinion.

EDIT: I mean the point of abbreviations is to facilitate communication. However with the world wide web connecting multiple countries, languages and fields of endeavour there are simply too many (for example) three letter acronyms in use. There are too many sources of ambiguity and confusion. Better to embrace long-form writing.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#268

So, exactly the same airline (French Bee) and exactly the same route (LAX-ORY) and exactly the same waypoint (DVL) as last September, resulting in exactly the same failure mode: https://chaos.social/@russss/111048524540643971 Time to tick that "repeat incident?" box in the incident management system, guys.

It's an article about that same accident

D'oh - the flight number was different and the lack of year on the post had me thinking it was just the same again.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#269

Earlier quoted context omitted.

... or there's a software engineer somewhere who simply assumed that three letter navaid identifiers were globally unique, and baked that assumption into the code. I guess we now need a "Falsehoods Programmers Believe About Aviation Data" site :)

And this is why you always use surrogate keys and not natural keys. No matter how much you convince yourself that your natural key is unique and will never change, if a human created the value then a human can change the value or create duplicates, and eventually will.

But that wouldn't help you here. The flight plan will come in with the code and you'll still have to resolve that to your keys.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#270

I guarantee that piece of code has a comment like /* This should never happen */ if (waypoints.matchcount > 2) {

From the text it sounds like it looked up if a code was in the flight plan and at which position it was in the plan. It never looked up two codes or assumed there code only be one, just comparing how the plan was filed.

I'm sure there'd be a better way to handle this, but it sounds to me like the system failed in a graceful way and acted as specified.

Post reply on HN