Bug: Stale results shown when re-running test after silent failure

[sridhar-panigrahi]

Summary

When running the speed test multiple times in the same session, previous results are not cleared from the UI.

If either NDT7 or MSAK fails silently during a re-run (e.g., due to a brief network interruption), the UI shows:

• Fresh results for the test that succeeded
• Old results from the previous run for the test that failed
• Status as "Complete"
• No visible error

This makes stale data appear as current results.

---

Expected Behavior

On re-run:

• All result fields should be cleared before the new test starts.
• If a test fails, its column should show an empty or error state.
• Users should never see results from a previous run.

---

Actual Behavior

• Internal JS state is reset.
• Result DOM elements are not cleared.
• If a test fails silently, its previous values remain visible.
• The UI shows "Complete" with no indication of failure.

---

Root Cause

In src/js/app.js, startTest() resets state:

this.measurementResult = {};
this.msakResult = {};

[M-V-RAGHUPATHI-SAI]

I have reproduced this network drop issue and wanted to add some technical devtools evidence.

While the state reset in startTest() explains why data stays stale on a re-run, the root cause of the app freezing and failing "silently" in the first place is actually an unhandled JS exception.

When the connection drops mid test, i have observed that theres an uncaught error Test failed: Error: TypeError: Failed to fetch (locate.measurementlab.net), it looks like its locking the UI, stopping the DOM cleanup or show any error messages, also there a lot of post requests from sentry failing but unable to send due to no internet.

Once check out this screenshot:

[sridhar-panigrahi]

Thanks for the additional evidence @M-V-RAGHUPATHI-SAI.

The scenario you captured (full network drop causing a fetch error
to locate.measurementlab.net) is one trigger, but the underlying
issue is broader — even when NDT7 fails without a network drop
(e.g., a single server being temporarily unavailable), the DOM
result elements retain values from the previous run because
startTest() only resets the JS state objects, not the DOM.

The fix needs to happen at the startTest() level — clearing all
result DOM elements before running either test — regardless of
what causes the failure downstream.

[Aaradhya-07]

Hi, I'd like to work on this Issue, I've been looking into the error handling UX and I believe the stale results problem is a part of a broader gap, when a test fails, the catch block currently sets measurementComplete = true , which shows the results with partial data and no error indication to the user

I previously raised PR #134 with an initial approach to this and got feedback to revisit this with more thought around UX

• what happens to the gauge
• partial results
• retry affordance
  PR fix: handle unhandled errors in ndt7 and msak test runners #173 has added JS-level error handling but there is still no user facing
  My proposed fix:

1. add a clearResults() method to wipe the previous DOM data at the start of each re run
2. Add a dedicated error section in the HTML
3. Add a testFailed state flag so updateUI() can distinguish success from failure and show the right section

I would like to know if we should show a complete error with a retry option(reference from speedtest by ookla ) or an error along side with results until the rest ran (reference from fast.com by netfix )

[sridhar-panigrahi]

Digging a bit deeper into this, I think there are actually two
separate problems at play here.

First, the stale DOM issue — when startTest() runs, it resets the
JS objects (measurementResult and msakResult) but doesn't touch the
actual DOM elements like #s2cRate, #c2sRate, #latency, #msakDownload,
etc. So if a test fails on a re-run, those elements just keep showing
whatever was there from the last successful run.

Second, the error state gets hidden from the user. When something
fails, the catch block writes "Error" into #currentPhase, which sits
inside the progress section. But then it sets measurementComplete to
true, and updateUI() immediately hides the progress section and shows
the results table. So the error message is there — the user just
never gets to see it.

There's also a subtlety with how ndt7 handles errors under the hood.
When a worker hits an error, it calls worker.resolve(1) instead of
rejecting the promise. That means ndt7.test() always resolves — it
never actually throws. The catch block in startTest() would only fire
if MSAK rejects or the locate service fetch fails completely. NDT7
failures are basically invisible to the app.

A few things I think are worth discussing before jumping into a fix:

• What should happen to the gauge when a test fails — freeze where
  it is, or reset?
• If one test succeeds and the other doesn't, should we still show
  the partial results with some kind of error indicator on the failed
  column?
• Does it make sense to have a retry option that's different from
  just clicking "Again"?

Would love to hear thoughts before writing any code.

[M-V-RAGHUPATHI-SAI]

I agree with @sridhar-panigrahi that resetting everything in startTest() is the best way to handle this.

Huge credit to @Aaradhya-07 for mentioning this issue since before the modernization : )

Also my devtools evidence confirms why clearing the DOM at the start and adding the testFailed state @Aaradhya-07 mentioned is so important.

Hey @Aaradhya-07, I'd love to team up, if you handle the clearResults() logic and state flags, i will handle the accessibility by implementing aria-live regions and announcements. this make sure that screen reader users are alerted to any failures.

what do you guys think?

[M-V-RAGHUPATHI-SAI]

I would like to know if we should show a complete error with a retry option(reference from speedtest by ookla ) or an error along side with results until the rest ran (reference from fast.com by netfix )

I think a complete error with a retry option(ookla style) is the better way. showing partial results could be misleading, to maintain M-Lab’s data integrity, i think we should avoid displaying any metrics from an incomplete test cycle. what do you guys think about this??

When the connection drops mid test, i have observed that theres an uncaught error Test failed: Error: TypeError: Failed to fetch (locate.measurementlab.net), it looks like its locking the UI, stopping the DOM cleanup or show any error messages, also there a lot of post requests from sentry failing but unable to send due to no internet.

also clearing the DOM and using the testFailed state will definitely fix the UI locking. but what about the errors still happening in the background?

[robertodauria]

General comment: I think in case of errors there should a proper "There was an error during the test, please try again." message. No partial results table or anything, just the error and the option to retry.

Also, please note that this issue is about stale results in case of errors. The fix for that is straightforward: clear the result DOM elements at the top of startTest(). This thread is turning it into an architecture discussion about error UX patterns, accessibility, partial results, gauge behavior, retry affordances, etc.

Please keep it on topic. Feel free to open a separate issue for how to handle errors during the test more generally and if you think we should do things differently (I do, personally, but this is still not the right place to discuss that).

What should happen to the gauge when a test fails — freeze where
it is, or reset?

Reset. The only thing to do in case there is an error during the test is to offer the option to retry it from scratch.

If one test succeeds and the other doesn't, should we still show
the partial results with some kind of error indicator on the failed
column?

No - an ndt7 test that does not last the intended time basically isn't a valid ndt7 test. TCP takes time to ramp up, so a much shorter test likely wouldn't give correct results. If the test fails at the downloadMeasurement/uploadMeasurement callbacks, for example, that's just ~250ms after the beginning of the test. The rate computed up to that moment isn't particularly useful.

Does it make sense to have a retry option that's different from
just clicking "Again"?

I think of clicking "Again" as the retry option - perhaps the text could be changed to "Retry" after an error?