Re: Test suite timing issues?

[Michael J Gruber <git@grubix.eu>]

[-- Attachment #1.1: Type: text/plain, Size: 1577 bytes --]

Am Sa., 12. Feb. 2022 um 21:45 Uhr schrieb Tomi Ollila <tomi.ollila@iki.fi>:

> On Sat, Feb 12 2022, David Bremner wrote:
>
> > Tomi Ollila <tomi.ollila@iki.fi> writes:
> >
> >> On Sat, Feb 12 2022, Michael J. Gruber wrote:
> >>
> >> Only thing that came into mind are directory timestamps... if directory
> >> (m)time is same as before notmuch will not scan it for files...
> >>
> >> ... following that if the granularity of directory timestamp were 1
> second,
> >> then it could easily happen than first one new message is not seen, and
> >> next time there is one extra message to be see...
> >
> > What do you think about adding --full-scan to the notmuch-new invocation
> > in add_message? It doesn't make any tests fail and is about the same
> > speed. I need to do a few more trials, but first time through it was
> > actually faster (!), maybe because the cache is hot
>
> Does such a change hide "buggy" functionality ?
>
> Or do we consider notmuch new buggy if it does not notice all new messages
> arrived every time ?
>
>
The timestamping sounds like a perfect explanation of what I've been
seeing. Unfortunately, I can't reproduce the issue "reliably" (with a
certain probability), and so if everything succeeds with --full-scan 10
times it still does not mean much.

As I understand, notmuch new without --full-sync may have issues when the
time resolution is too low (or operations too fast) and will pick a message
on the next run, so it's not really buggy - it uses a shortcut that may be
too quick but does not loose messages in the long run.

Michael

>
>

[-- Attachment #1.2: Type: text/html, Size: 2321 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]