Cancel Diagnostics button not action immediately

[JohnnyWuLinksys]

Description
When diagnostics ongoing, it shows "Cancel Diagnostics" button
However click it doesn't stop diagnostics, it takes action after all items done.
(will go back to Network Diagnostics page)
log-2026-07-16_16_09_57_cancel_diagnostics_button_not_action_immediately.txt

Steps

1. Menu > Network Diagnostics
2. Click "Start Now" button on "Run Full Diagnostic" section
3. Click "Cancel Diagnostics" button

Current result
Action still ongoing

Expected result
Action should stop immediately

Information
Pinnacle 2.0 FW: 1.2.2.26062820
Linksys Now Version: 2.5.0.700525

Severity
S3

[AustinChangLinksys]

🔍 Automated investigation (preliminary triage)

Line: 2.x / USP (TR-369)

Root cause (single-layer UI / state-management defect — no backend error involved):

• UI defect: cancel() sets _cancelled = true but then awaits the entire in-flight run future before releasing the scope. The full-diagnostic flow (_runFullDiagnosticFlow) only checks if (_cancelled) return; once at the very top; the ~10 sequential awaited steps that follow (ping gateway/DNS/internet, DNS lookup, shared speed test, WiFi signal, DHCP pool, mesh backhaul, connected devices) have no interleaved _cancelled guards. So once the flow is past its entry check, pressing "Cancel Diagnostics" cannot short-circuit it — every remaining step runs to completion first, and only then does the awaited cancel() complete and reset state. This exactly matches the reported "it takes action after all items done (goes back to Network Diagnostics page)".

Evidence (from attached UI log):

1. User's cancel fires mid-flow at 16:09:10.614 (right after the DNS-lookup step), yet the pipeline keeps executing subsequent steps:

2026-07-16T16:09:10.562 [D][Diagnostics] NSLookup www.google.com complete: Complete
2026-07-16T16:09:10.614 [D][Diagnostics] Cancelled
2026-07-16T16:09:10.698 [D][Diagnostics] Pinging Internet 1.1.1.1
2026-07-16T16:09:11.060 [D][Diagnostics] Ping 1.1.1.1 complete: Complete
2026-07-16T16:09:11.060 [D][Diagnostics] Starting shared speed test
2026-07-16T16:09:11.060 [D][Diagnostics] Calling runSpeedTest()

2. The speed test (the long step) still runs to full completion ~10s later, followed by every remaining check — the flow ignores the cancel entirely and finishes normally:

2026-07-16T16:09:21.755 [D][Diagnostics] SpeedTest completed
2026-07-16T16:09:21.755 [D][Diagnostics] Analyzing WiFi signal per radio
2026-07-16T16:09:25.126 [D][Diagnostics] Checking DHCP pool usage
2026-07-16T16:09:25.489 [D][Diagnostics] Inspecting mesh backhaul
2026-07-16T16:09:25.775 [D][Diagnostics] Checking connected devices
2026-07-16T16:09:25.956 [I][Diagnostics] Complete — 0 recommendations

3. No backend error occurred — every USP operation returned Status: Complete; there is no JNAP _Error*, no USP failure code, no non-200. This is structurally a UI/state-management gap, not a firmware/backend problem:

grep for "result":"_Error*" / UspFailure / "error"  →  0 matches
All OperationComplete payloads: "Status":"Complete"

Suggested direction (for maintainer review, not a commitment): add if (_cancelled) return; checks between the sequential awaited steps inside _runFullDiagnosticFlow (and the other per-flow runners), so cancellation takes effect at the next step boundary instead of only after the whole flow completes. A cooperative cancellation token threaded into the long-running speed-test step would also let it abort promptly.

Confidence: High — root cause confirmed by reading code at the reported version (dev-2.5.0, Linksys Now 2.5.0.700525) cross-referenced with the attached log's step timeline; single-layer UI defect with behavioral evidence.

---

Auto-generated triage by Austin's tooling, pending Austin's review. Not a fix commitment.