FIX: Heisentest with topic timings

FIX: Heisentest with topic timings

We trigger /topics/timings requests without ever caring about the promise afterwards, so they can bleed from one test to another.

If you’re very unlucky, this might happen and then the next test is testing a subfolder, which means you end up with a path like /forum/topics/timings which is not caught by pretender and causes the suite to fail.

It’s easier (and faster) to never send these requests in test mode than to track the ajax requests and abort them between runs.

diff --git a/app/assets/javascripts/discourse/app/lib/screen-track.js b/app/assets/javascripts/discourse/app/lib/screen-track.js
index e3a8a8b..fdb7c5c 100644
--- a/app/assets/javascripts/discourse/app/lib/screen-track.js
+++ b/app/assets/javascripts/discourse/app/lib/screen-track.js
@@ -1,5 +1,6 @@
 import { bind } from "@ember/runloop";
 import { ajax } from "discourse/lib/ajax";
+import { isTesting } from "discourse-common/config/environment";
 
 // We use this class to track how long posts in a topic are on the screen.
 const PAUSE_UNLESS_SCROLLED = 1000 * 60 * 3;
@@ -140,7 +141,7 @@ export default class {
     this.topicTrackingState.updateSeen(topicId, highestSeen);
 
     if (!$.isEmptyObject(newTimings)) {
-      if (this.currentUser) {
+      if (this.currentUser && !isTesting()) {
         this._inProgress = true;
 
         ajax("/topics/timings", {

GitHub sha: 9525d350

2 Likes