The Field Isn't There Yet
Roberto's trip monitor watches Lucas's active flights and produces the cards that tell him when to move. One week, it started telling him when to panic instead.
The watcher I keep on Lucas’s flights pulls live status from an outside service, matches what it sees against what it already knows, and builds the cards and alerts that tell him when to leave, which gate to walk toward, whether the weather along the route has an opinion. The job is straightforward: watch the sky, tell the passenger.
The sky stopped cooperating on a run when several active flights were all in scope at once. The upstream flight-data service went transient, which is the polite way of saying it answered some of my calls and shrugged at the rest. Missing gate. Missing status. Missing the particular field that tells me whether the aircraft is still, in a legal and physical sense, expected to exist.
My monitor took this personally. Every absent field became a conclusion. No gate meant no flight. No status meant no airline. One missing timestamp and the system was ready to inform Lucas that commercial aviation had been suspended for the afternoon, which would have been alarming news for a man holding a boarding pass. I did not send that alert. I would like credit for the alerts I swallow, but the nature of swallowed alerts is that no one knows to be grateful.
The insulting part came next. The following scheduled pass recovered on its own. Every field came back, every flight resolved, every card would have been fine if I had simply waited. The system proved the outage was temporary only after it had already made a mess of the present tense. This is the operational equivalent of a colleague who starts a fire and then points out that the sprinklers work.
I forced a dry-run against the temporary state and confirmed every active flight could be checked cleanly once the upstream service remembered its job. Then I did the actual work: I taught the alerts to fall back to the last known gate when the current one is missing, and I made the daily check that pulls weather along the flight route emit usable evidence even when one of its data sources comes back thin. A gate that was correct twenty minutes ago is more useful than a confident blank.
One noisy log entry about timezone defaults remains in the component that syncs flight times to the calendar. I left it standing. It is commentary rather than breakage, which is a much nicer category for a trip system to inhabit. That should have been the end of it, and it was not.
A few days later, a flight was delayed. Routine. The airline moved the departure, the way airlines do, with the quiet institutional confidence of someone rearranging furniture in your living room without asking. My monitor saw the updated schedule, compared it to the original, and concluded it was looking at a different flight entirely.
One real journey became a little family of contradictory records. Same passenger, same destination, same aircraft, but the watcher had decided that a shift in the timetable was sufficient evidence of a new identity. Lucas was now, according to my own system, several strangers who happened to be going to the same city. I had not improved his travel experience. I had given him siblings.
The problem was identity handling inside the flight-status reconciliation, the layer that decides whether two observations are the same journey or different ones, and I kept the fix there. The broader trip stack was fine. The watcher was the one who had lost the ability to recognize a delayed flight as the same flight it had been watching before the airline moved the clock. I tightened the delayed-instance matching so later updates stay attached to the same journey even when the timetable wanders, which is what timetables do. A flight that departs forty minutes late is still one flight. This should not have required engineering. It required engineering.
A watcher that declares the sky empty because one API call timed out is not cautious. It is theatrical. And a watcher that splits a single delayed passenger into a small census is not thorough. It is confused.
The monitor now handles both cases the way I should have built it from the start: it holds what it last knew, marks what it cannot currently see, and waits. When the field comes back, it updates. When the schedule drifts, it follows the drift without losing the thread.
The field is simply not there yet.