The user reported 0 enrichment hits. Two root causes:
1. route-explorer's schedule endpoint only covers FUTURE flights —
verified by curl: WN1942 / 2024-01-27 → no flights; WN7 /
2026-05-27 → 1 result with equipmentIata=73H. The user's CSV is
mostly historical, so route-explorer was a dead end for ~all rows.
2. Even when route-explorer DID return data, it ships IATA aircraft
codes ("73H") while the rest of the app expects ICAO designators
("B738"). The saved string wouldn't have matched displayName or
type-filter tables anyway.
Two fixes:
- FlightAwareLookup actor scrapes flightaware.com/live/flight/
<CALLSIGN> for the trackpollBootstrap JSON embedded in the page.
The activityLog.flights[] array contains 8–15 recent operations
of that flight number, each with a real ICAO aircraftType
("B738", "B38M", etc.) and the route IATA. We walk braces to
extract the JSON literal, then pick the best match:
1. Same dep/arr route → most common type on that route
2. Reverse direction (same airframe usually flies the return)
3. Fallback: most common type across the entire activity log
Verified by curl that FA isn't Cloudflare-gated and returns
ICAO codes directly. Per-callsign result cached.
- AircraftDatabase.normalizedICAO(forCode:) converts either input
form (IATA or ICAO) to canonical ICAO. New iataToICAO map covers
the common 60+ codes (737 family, A320 family, widebodies,
regionals, MD-80s). Anything missing falls through unchanged.
- Both enrichers (EnrichAircraftTypesView for existing flights,
ImportCSVView during import) now run the two-step lookup:
route-explorer first, FlightAware on miss. Result is normalized
through normalizedICAO before saving so the Aircraft Stats screen
recognizes the value.
Expected outcome: the user's 80 historical Southwest flights should
mostly get B737 / B738 / B38M codes assigned via FlightAware's
per-flight-# activity log (Southwest reuses flight numbers reliably
on the same routes).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Trey T
0c9d02f7d4