You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reading parser.py, specifically the _find_config_doc(self, callsign) routine. It's tried to first find a flight doc, but if the flight doc has expired it looks for the latest payload_config containing the callsign. However, a issue arises, when the fligh doc has expired during a flight in progress, where the flight doc is using a older payload_config, while newer payload_config exists.
The last part of the routine, would always select the newest payload_config and attempt to parse data with it. If the format is different, it would fail to parse the flight as it happened to SP3OJ's flight.
My question is, should habitat instead select the latest flight containing the callsign and use the payload_config off of that or should users recreate the payload config for each flight, even if it's a duplicate?
The text was updated successfully, but these errors were encountered:
Going for old but approved flight docs might make sense before looking for latest payload docs (which we'd still do as a final fallback if no flight docs have the payload).
The problem here is that if you want to test a new payload config document, your old flight document will always take precedence -- so you could never test a new payload on the same callsign without making (and having approved) a flight for it.
On balance it seems like helping users whose flight docs have expired is less useful than preventing testing. Can anyone think of a way around that?
Reading
parser.py
, specifically the_find_config_doc(self, callsign)
routine. It's tried to first find aflight doc
, but if the flight doc has expired it looks for the latestpayload_config
containing the callsign. However, a issue arises, when the fligh doc has expired during a flight in progress, where the flight doc is using a olderpayload_config
, while newerpayload_config
exists.habitat/habitat/parser.py
Line 299 in 6884dae
The last part of the routine, would always select the newest
payload_config
and attempt to parse data with it. If the format is different, it would fail to parse the flight as it happened to SP3OJ's flight.My question is, should habitat instead select the latest flight containing the callsign and use the payload_config off of that or should users recreate the payload config for each flight, even if it's a duplicate?
The text was updated successfully, but these errors were encountered: