Subject: bug#75906: 30.0.93; track-changes-tests--random failure

From: Stefan Monnier <[email-masked]>
Date: Sun, 02 Feb 2025 18:13:47 -0500

forcemerge 75906 73041
thanks

Hi,

It looks like those two bugs are one and the same.

> > Hmm... that's weird.  I tried:
> >
> >     src/emacs --batch -Q                                              \
> >               --eval '(setq track-changes-tests--random-seed 814217)' \
> >               -l test/lisp/emacs-lisp/track-changes-tests.elc         \
> >               --eval '(ert-run-tests-batch-and-exit t)'

Duh!  It was just a pilot error on my end: the seed needs to be
a string.  After fixing the above to use

    (setq track-changes-tests--random-seed "814217")

I was able to reproduce the problem locally.

> It looks like this test may be flaky.

It's randomized (which is why it prints the seed it used, so you can
try and reproduce it reliably once it hits a problem).

> | Test track-changes-tests--random backtrace:
> |   cl--assertion-failed((not (memq id track-changes--clean-trackers)))
> |   track-changes-fetch(#s(track-changes--tracker :signal #f(compiled-fu

After finding the origin of the problem, I think that the better fix is
to adjust the assertion.  The better short term fix for `emacs-30` is to
simply comment out this assertion.

Any objection to pushing the patch below to `emacs-30`?

        Stefan

diff --git a/lisp/emacs-lisp/track-changes.el b/lisp/emacs-lisp/track-changes.el
index 3f3b8d7bed9..1aac53b5f33 100644
--- a/lisp/emacs-lisp/track-changes.el
+++ b/lisp/emacs-lisp/track-changes.el
@@ -364,7 +364,9 @@ track-changes-fetch
                              track-changes--state))
               ;; Nothing to do.
               nil)
-          (cl-assert (not (memq id track-changes--clean-trackers)))
+          ;; ID may still be in `track-changes--clean-trackers' if
+          ;; `after-change-functions' was skipped.
+          ;;(cl-assert (not (memq id track-changes--clean-trackers)))
           (cl-assert (<= (point-min) beg end (point-max)))
           ;; Update the tracker's state *before* running `func' so we don't risk
           ;; mistakenly replaying the changes in case `func' exits non-locally.