That comes from the wm-zuul-status JavaScript plugin https://gerrit.wikimedia.org/g/operations/software/gerrit/+/refs/heads/deploy/wmf/stable-3.10/plugins/wm-zuul-status.js

On each fetch of results, the plugin invokes hasCompletedCheck():

/**
 * Whether some previous check vanished from CI
 *
 * Note: this reset the internal state and must be called only once.
 *
 * @return {boolean}
 */
hasCompletedCheck() {
  let completed = false;
  for (const prev of this.prevChecks) {
    if ( !this.curChecks.has(prev) ) {
      // A check name is no more being processed
      completed = true;
      break;
    }
  }

  // Keep a copy and reset current state
  this.prevChecks = new Set(this.curChecks);
  this.curChecks = new Set();

  return completed;
}

When navigating from a change to another one, it looks like the code compare the list of checks from the previous change, notice they are no more being processed and thus assume the checks have been completed.

The prevChecks and curChecks should also be reset when navigating out of a change. Maybe they can be cleaned when the change changed:

  /**
   *
   * @param {ChangeData} change
   * @return {Promise<FetchResponse>}
   */
  async fetch(change) {
    return this.getZuulStatus(change.changeNumber, change.patchsetNumber)
      .then( statusJson => {
        const checkRuns = this.parse(statusJson);

        if ( this.hasCompletedCheck() ) {
          this.showAlertToReloadChange();
        }
...

The change object is passed to it which is convenient. The change can be passed to hasCompletedCheck which would track the current and previous change.

@A_smart_kitten thank you so much for having filed that task. I did notice the popup showing up but never went to spend time finding why it happened :-] I will look at fixing it eventually.

In T394485#10829225, @hashar wrote:

@A_smart_kitten thank you so much for having filed that task. I did notice the popup showing up but never went to spend time finding why it happened :-]

No problem! :D

Change #1146976 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.10] wm-zuul-status: do not popup when navigating changes

https://gerrit.wikimedia.org/r/1146976

Change #1146976 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.10] wm-zuul-status: do not popup when navigating changes

https://gerrit.wikimedia.org/r/1146976

Mentioned in SAL (#wikimedia-operations) [2025-05-16T13:21:43Z] <hashar@deploy1003> Started deploy [gerrit/gerrit@fcb893c]: wm-zuul-status: do not popup when navigating changes - T394485

Mentioned in SAL (#wikimedia-operations) [2025-05-16T13:21:55Z] <hashar@deploy1003> Finished deploy [gerrit/gerrit@fcb893c]: wm-zuul-status: do not popup when navigating changes - T394485 (duration: 00m 12s)

@A_smart_kitten I have tested my fix with the browser debugger and it worked for me. I have deployed it and that should fix it for everyone.

Thanks @hashar! Testing it myself, the popup does still seem to appear when it shouldn't do, though (albeit with a bit more of a delay).

Debugging in my browser, I think it might have something to do with the following:

• After the patch from yesterday, this.prevChecks is set to an (empty) new Set() after the user has navigated to a new change. (https://gerrit.wikimedia.org/r/c/operations/software/gerrit/+/1146976/1/plugins/wm-zuul-status.js#167)
• However, the value of this.curChecks is not modified to remove any checks that relate to the previous change. Because of this, on the second call to hasCompletedCheck(), it looks like prevChecks will be set to the pre-existing value of curChecks (which will still contain checks from the previously-viewed change). (https://gerrit.wikimedia.org/r/c/operations/software/gerrit/+/1146976/1/plugins/wm-zuul-status.js#181)
• Because of that, on the third call to hasCompletedCheck(), the software will once again be comparing prevChecks data that relates to a previous change to an empty curChecks set; and therefore will incorrectly display the 'CI has completed checks' popup message.

Change #1148286 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.10] wm-zuul-status: reset current checks

https://gerrit.wikimedia.org/r/1148286

Change #1148286 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.10] wm-zuul-status: reset current checks

https://gerrit.wikimedia.org/r/1148286

Mentioned in SAL (#wikimedia-operations) [2025-05-20T09:51:11Z] <hashar@deploy1003> Started deploy [gerrit/gerrit@2ecc180]: wm-zuul-status: reset current checks - T394485

Mentioned in SAL (#wikimedia-operations) [2025-05-20T09:51:22Z] <hashar@deploy1003> Finished deploy [gerrit/gerrit@2ecc180]: wm-zuul-status: reset current checks - T394485 (duration: 00m 11s)

@A_smart_kitten thank you for the detailed report! Indeed curChecks was not cleared between parse so the pipelines kept being appended to the list or the state was not reset. I have sent a hack that should clean it now.

Note to self: the state is managed in both parse() and hasCompletedCheck() which is confusing. That should probably be entirely managed within parse().

Thank you for the very two reports and verifications! Eventually I should overhaul the code to make it nicer, but that is for the future :)