3 ms·
We know. That's clear to everyone here. But clearly in their design of the system they hadn't considered it. I'm sure no doubt they will now fix the issue, but
by ChrisRR 3y ago
We know. That's clear to everyone here. But clearly in their design of the system they hadn't considered it.
I'm sure no doubt they will now fix the issue, but you can only aim to handle faults that you predict during development, plan for unexpected faults, and hope that something super unexpected doesn't cause cascading faults
- zimpenfish 3y ago> But clearly in their design of the system they hadn't considered it. They might well have considered it the possibility of duplicate tags in the same flight plan but since identical tags are supposed to geographically distinct, they probably didn't further consider a flight plan where the entry and exit points from the UK (which is a relatively small airspace, I think) are the same tag (since it sounds from the report they did that this was an extremely weird flight plan.)
- krisoft 3y ago> That's clear to everyone here. Are you sure? Have you also consulted with zimpenfish? From their comment it seems they disagree. > hope that something super unexpected doesn't cause cascading faults But that is the thing. Processing failing isn’t and shouldn’t be “unexpected”. Here the individual processing items are flight plans, but the concept is more general. They could be “requests” to a web server, they could be “tasks” in an async worker node, they could be “transactions” in a database, if you do any compute with a work item it can fail. You need to put a big “try-catch” around it and add a field in your database or queue or remote procedure call system to mark them as failed. One work item failing shouldn’t be “super unexpected”. Even if you can’t name the exact conditions under witch it might fail.