dneuge
commented
3 years ago Flight plan revision numbers have been removed from JSON v3 format and graph import needs to be adapted to work without that information in the future (#13). That change in processing may result in this issue being solved for legacy files as well. #13 will check compatibility for old and new data files.
Flight plan revisions can roll back while maintaining airport pair, member and callsign.
Prefilings are currently not checked for revision rollbacks. This leads to implausible situations after graph import where a lower revision has been seen in a later report than a higher revision. Ocassionally importer-status-postgis will fail to load data back from database as this violates constraints required for internal graph reconstruction. As the data is generally implausible and should never have been imported like that, this is a bug in graph import.
Flights are already checking such rollbacks which resulted in sometimes unnecessary splits (see #1). An attempt to add a simple check failed due to spurious splits of connected flights into tracking data and prefiled flight plans or duplicate prefilings showing up in datafiles leading to multiple recordings of identical flights (d44cf6229d398de982a9b984881806dced733cb3).
An example for implausible data is UAE858 on 3 Aug 2020: While connected, a prefiling appeared as revision 1 at 1725z and got reset to revision 0 at 1759z. Because there was no prior revision 0 seen in datafiles (might have been too short-lived or some VATSIM-side data export error), the later revision 0 was added to the same flight in front of revision 1. If that graph data is saved to DB and then reloaded, graph reconstruction fails as revisions are supposed to be strictly ascending in revision and report record time.
Introducing generations to flight plan revisions as described in #1 could solve this issue.