mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
Maurice
4cab17a6b9
AirTrail 3.12.0 renamed the flight's passenger list from `seats` to `passengers` and moved flightReason from the flight onto each passenger. There is no alias in either direction: a 3.12.0 instance returns `passengers` and `null` for `seats`, and its save schema accepts only `passengers`. TREK read `raw.seats` everywhere, so against a 3.12.0 instance it found nothing. The seat never made it into the import, and because a pull rebuilds the metadata from the AirTrail payload, flights that had already been imported lost the seat they had. That is the report. Flights whose sync is switched off were never re-pulled, which is why theirs survived. Two more breaks came from the same rename and were not reported. The flight reason stopped importing for the same reason. And the writeback pushed the seat under `seats`, which the new schema strips, so a seat edited in TREK was quietly dropped on the way out; it did not fail loudly because the spread of the fetched flight carried AirTrail's own `passengers` through untouched. Both shapes are handled rather than switched between, because instances on 3.11 and older are still out there: reads take `passengers ?? seats`, and the save body carries the manifest under both keys. Neither schema is strict, so each version keeps the key it knows and strips the other. The snapshot hash deliberately keeps feeding the manifest in under the same key. An unchanged flight on an older instance therefore hashes exactly as before and does not re-sync, while a 3.12.0 flight hashes differently once and pulls the missing seat back in. There is a pinned-hash test guarding the first half. Verified against real instances rather than the docs: a 3.11.1 and a 3.12.0 container, seat imported from each, a seat edited in TREK written back and read out of AirTrail again, and the pre-fix build failing the same checks on 3.12.0. Closes #1931