fix: initiate hold after overflight when handoff accepted - #14
Merged
Conversation
When another sector originates a hold and the aircraft overflies the hold point before the handoff is accepted, InitiateHold skipped the overflown waypoint and silently bailed, so the hold never appeared in our list. Reuse the same lookback logic as the parser and segment finder.
When a handoff is accepted, vatSys may swap the FDR object. The new FDR already has IsTrackedByMe=true before we subscribe, so no PropertyChanged event fires for the transition and OnFDRPropertyChanged never runs. The sync block in SubscribeToAllFDRs only updated existing holds; extend it to also initiate holds for tracked FDRs with hold text but no existing hold item.
InitiateHold was gated on IsTrackedByMe, so a flight in the handover-in phase (IsHandoff=true, IsTrackedByMe=false) wasn't tracked until the handoff was accepted. UpdateHoldItemFromFDR already supports the Handover state, so allow initiation when either flag is set.
HoldEntryTime was set once from holdSegment.ATO at hold creation, but ATO is only populated when the aircraft actually overflies the hold point. Holds created before overflight ended up with a default entry time that never updated. Re-read ATO in UpdateHoldItemFromFDR so the entry time reflects the actual overflight time once available.
FDR.IsHandoff and FDR.HandoffController don't cleanly distinguish incoming-handoff-accepted from outgoing handoff: HandoffController can remain set after an incoming accept, leaving the item stuck in the Handover state and colour. Read MMI.HMIStates from the track instead, which has the unambiguous transitions we need (Jurisdiction, HandoverIn, HandoverOut). Initiation gates also use the same helper for consistency.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hold tracking didn't kick in for flights handed off to us, and once it did the state often got stuck. This PR fixes:
HoldEntryTimenever refreshed fromholdSegment.ATOonce the aircraft actually overflies.IsHandoff/HandoffControllersemantics. State is now derived from the track's HMI state.Fixes #13
Fixes #15