A QGroundControl issue opened on 28 October 2026 identifies a specific example. Its author found that the Fly View controls for Continue Mission and Resume Mission compare a MAVLink mission sequence number with the count of visual items displayed by QGroundControl. Those quantities are not guaranteed to describe the same things. The report is based on code inspection, and the author explicitly says the defect had not yet been reproduced in SITL when filed. That qualification matters: this is a technically supported regression hypothesis, not a confirmed in-flight incident.
The wire protocol counts commands; the map groups them
The MAVLink mission protocol transmits a numbered list of mission items. Each MISSION_ITEM_INT has a seq field. The sequence starts at zero and advances without gaps. Navigation commands share that ordered list with other actions such as speed changes and camera commands. The MISSION_CURRENT message announces the currently targeted mission sequence number; its optional total extension reports the vehicle's item count, with qualifications for systems that store home as a mission item.
A map-based planner has a different job. It needs to present an understandable route. QGroundControl's mission controller can fold camera-trigger and speed instructions into a waypoint's settings, and collapse a fixed-wing landing approach into a single complex visual item. That is useful interaction design, but a visual item's position is no longer necessarily a MAVLink command's sequence number.
Consider a hypothetical mission whose wire-format list contains five commands: waypoint A, camera trigger, speed change, waypoint B and land. A plan view might display far fewer than five separate items because the trigger and speed change belong visually to waypoint A. The exact QGroundControl representation depends on the command type and how the mission was loaded. The numerical mismatch is the point, not the example's exact number of icons.
A test that asks whether the active wire-protocol index is less than visualItems.count - 1 can therefore return false even while valid mission commands remain. It compares a position measured in raw commands against a boundary measured in grouped UI objects.
The reported regression has a traceable code path
The 28 October issue names three relevant locations in QGroundControl:
GuidedActionsController.qmltests whether to show Continue or Resume using_visualItemsCount.MissionController.ccsupplies the current and resume mission indices in MAVLink sequence space, with firmware-dependent home handling.- The mission reconstruction code folds several command types into visual items after downloading a mission, including in Fly View.
The reporter traces the original raw-command count back to a change made during a Qt 6 TreeView fix, pull request #14161. A later refactor removed the old missionItemCount property and used visualItems.count directly. An earlier issue, #14162, focused on a simpler off-by-one question about an internal MissionSettingsItem. The newer report argues that adjusting that one offset would leave the deeper problem intact.
This is why a fix needs a semantic boundary, not another magic subtraction. A count of points drawn on the screen cannot safely stand in for the last executable command sequence number.
Why the missing action can be operationally expensive
The reported condition affects the availability of a ground-station action. The cited issue does not establish that an autopilot has stopped executing a mission or lost it from storage. Those are different failures.
Still, the unavailable control could be inconvenient at exactly the wrong time. A mapping crew might leave mission mode to resolve an airspace conflict, then expect a continuation option. A survey paused for a battery replacement might need a resume option to avoid repeating coverage. The report specifically identifies camera-triggered surveys and landing patterns as missions where the visual-to-command mismatch grows.
Resuming the mission has a second, separate meaning: where will the aircraft rejoin its route? ArduPilot's mission rewind documentation explains why simply directing an aircraft toward the last active waypoint can leave gaps in survey data after a diversion. Its configurable rewind distance addresses route coverage, not QGroundControl's decision to display a Resume button. A ground-station fix would not eliminate the need to evaluate the aircraft's actual rejoin trajectory.
The distinction between firmware families also matters. The QGroundControl report notes different handling of the home item in ArduPilot and PX4, so a threshold that seems correct for one firmware can be wrong for the other. ArduPilot Plane documentation also makes mission restart or continuation dependent on MIS_RESTART. A usable UI control cannot override the aircraft's configured mission behavior.
What a defensible fix and test would look like
The minimal engineering requirement is to compare quantities in the same unit. The issue proposes using the underlying MissionManager's command count or the last visual item's lastSequenceNumber, rather than the number of visual objects. Either approach needs review of home-item offsets, zero-based indexing and the end-of-mission case. The existing Resume check reportedly includes a - 2 adjustment intended to suppress resume when a mission ends in RTL. Examining the actual final command would be more explicit than encoding that special case in a count.
A regression suite should exercise both the rendering and the protocol boundary, with SITL rather than an operational aircraft:
- Upload a plain-waypoint mission, a survey containing folded camera/speed instructions, and a fixed-wing landing-pattern mission.
- For each mission, record the raw uploaded command count,
MISSION_CURRENT.seq, the rendered visual count and the last executable sequence number. - Interrupt at a sequence that is above the visual count but below the true final command. Check whether Continue remains available.
- Repeat after a simulated landing to check Resume, then test ArduPilot and PX4 separately because their home-item conventions differ.
- Verify that the action is absent once the mission genuinely ends and that an RTL-ending mission is handled by inspecting its command, rather than assuming its position.
These are proposed test conditions drawn from the reported code path, not a claim that the defect has already been reproduced in these combinations. The MAVLink mission specification defines the numbering used to make the checks objective.
What operators can conclude today
An apparently missing Continue or Resume option is not enough by itself to diagnose this bug. Other explanations include mission state, a completed mission, firmware settings or an unavailable operation. The issue is open and its original evidence is a code-level analysis. Its author says QGroundControl 5.1.0 through 5.1.5 may be affected and asks for a stable-branch backport, but a fix and a verified affected-version matrix were not established in the material reviewed.
For a crew designing an interrupted-survey procedure, the useful precaution is to validate its exact firmware, ground-station build and mission shape in simulation, including the post-interruption rejoin path. Record both the UI state and the vehicle's mission sequence values when investigating an anomaly.
The broader lesson is a software boundary that applies well beyond this one issue: flight controllers execute ordered commands, while planning interfaces compress them into human-readable objects. When a safety-relevant action depends on progress through a mission, the program must measure progress in the flight controller's command sequence, not in the number of things drawn on the screen.