Maxim Mikityanskiy <[email protected]> wrote: > On Tue, Feb 14, 2023 at 02:42:32AM +0000, Eric Wong wrote: > > Maxim Mikityanskiy <[email protected]> wrote: > > > lei q --no-save -a -o /tmp/lei-test -I 'https://lore.kernel.org/all' \ > > > -tt 'a:syzbot AND rt:2023-01-01..2023-01-07'
<snip> > > Yes, now it seems it's the collapsing optimization. <snip> > Sorry for taking too long, I finally found a minute to test it, and > unfortunately I didn't see a difference. I queried for: > > a:syzbot AND rt:2023-02-01..2023-02-07 > > and I still saw I lot of threads without a single flag. > > I double-checked that the patch was actually applied, killed lei-daemon, > and removed the mailbox directory, but it didn't help. Ah, oops. My original fix only works for locally-cloned inboxes; but not remote (http/https) inboxes... I think some inconsistency on the client side is also introduced by using -I/--include vs --only; since -I/--include will use previously-indexed messages in ~/.local/share/lei/store Getting -tt to work on remote inboxes will take more effort. I'm not sure which option is better: 1) Support t=2 natively in the WWW interface. This requires both the server and client to be updated. It may require extra dedupe step on the server, making it more expensive. Thinking out loud, I think the dedupe step can be avoided by sorting on THREADID... 2) use t=1 in the client as-is, but index the streamed mbox locally, first. This requires a temporary Xapian DB to ensure there's no overlap if using --only. This only requires a client update, but likely adds more complexity. It also delays updates to the Maildir, meaning all messages need to be downloaded before the MUA sees it... I'm leaning towards 1...
