Thanks Uwe, the site/status is refreshed for LFV-130 (https://shbhar.github.io/lucene-ai-bug-hunt/?wontfix=1&q=LFV-130)
The one I had picked earlier (https://shbhar.github.io/lucene-ai-bug-hunt/bugs/LFV-002.html) is much harder to understand than I initially expected (a merge race bug for buffered doc value updates), so I'm picking some easier ones in the meantime to give my brain a break! On Thu, 29 Oct 2026 at 14:42, Uwe Schindler via dev <[email protected]> wrote: > > I opened a bug report (https://github.com/apache/lucene/issues/16951) to fix > documentation and left a comment in > https://github.com/apache/lucene/issues/16937. > > Uwe > > Am 29.10.2026 um 18:35 schrieb Uwe Schindler via dev: > > Hi, > > I misunderstood LFV-140, actually it is not problem: > https://shbhar.github.io/lucene-ai-bug-hunt/repro/LFV-130/ > > This one complains about after an EOF happened, the IndexInput behaves > "wrong" under some circumstances. It might be improved, but the trick I > mentioned before with reporting correct exception is fine. Actually once an > IOException happened, an IndexInput should no longer be used because its > state may be corrupted. Plain simple! Maybe we should add documentation to > IndexInput base class that after an IOException the state of an IndexInput is > "undefined" and spurious exceptions may or may not happen. > > If I have a cheap way how to improve that (so it will always throw > EOFException), I will patch it, but otherwise this issue is rejected. > > Uwe > > Am 29.10.2026 um 17:28 schrieb Shitij Bhargava: > > Thank you Uwe. > > There are also some apparently unreported bugs that only appeared in > 10.6 and were not in 10.5.2 (5 medium priority and others low > priority, based on AI's classification) - I've updated the website to > be able to filter to only these with the "Only bugs new in 10.6" > option if it helps. > > I don't want to create unnecessary confusion for everyone at the last > moment (I see 10.6 release is imminent), but if someone can glance at > them for a sanity check, it might be helpful. I'm also prioritizing > understanding these first (starting with > https://shbhar.github.io/lucene-ai-bug-hunt/bugs/LFV-002.html) > > Thanks, > Shitij > > On Thu, 29 Oct 2026 at 01:06, Uwe Schindler via dev > <[email protected]> wrote: > > Hi, > > the wrong offset in error message for multi-mmap may be fixed easily, I > will have a look. Actually in the recent version the wrong offsets are > reported through a private method throwing the exception. I can override > that in the subclass. I have to closer look, but I will post a PR once > ready. > > Anyways: I will have a look at all the mmap-related bugs. > > Uwe > > Am 29.10.2026 um 06:27 schrieb Shitij Bhargava: > > Quick update: > > Refreshed the site with the above 2 bugs to be correctly classified as > previously known instead of new since they were known privately (and > triaged to in-progress and wont fix). > > Also Uwe for your feedback in > https://github.com/apache/lucene/pull/16931#issuecomment-6476410908 > for unnecessary tests, I'm instructing the agent to be more > disciplined/minimal with a second pass in not just the repro but also > in its unit tests (currently in progress) > > Thanks, > Shitij > > > On Wed, 28 Oct 2026 at 14:45, Shitij Bhargava <[email protected]> wrote: > > Thank you Uwe and Chris! > > For automatically refreshing, I think it would help if the agent can > just poll 1 link/github issue and keep the website updated with new > triages, fixes, verified/opened issues etc. So I've made it here: > https://github.com/apache/lucene/issues/16937 > > For the two issues you mentioned, I will work on refreshing the > website for both (like adding a triaged/triaged by column?) and update > here. For LFV-037 (shared arena one) it will update to fix in progress > in #16931 & for LFV-135 (multi-mmap offset) it will say "won't fix". > For future updates just linking to the above issue or triaging there > in natural language would work automatically as well. > > If it makes sense I can make it so that an expert in certain area can > search by their name or github handle and it will show a list of bugs > which might be related to their expertise (based on AI's assessment) > instead of having to manually scan the whole table. > > Let me know if any other features in the website or the whole process > would help! > > Thanks, > Shitij > > On 2026/10/28 17:45:52 Uwe Schindler via dev wrote: > > Hi, > > here is the first PR fixing that issue, thanks to Chris! > https://github.com/apache/lucene/pull/16931 > > Not sure how to keep track of this resolved issue in your AI report: > https://shbhar.github.io/lucene-ai-bug-hunt/repro/LFV-037/ > > Uwe > > Am 28.10.2026 um 15:16 schrieb Uwe Schindler via dev: > > Hi, > > thanks for the great web site with all those bugs. I scrolled through > them and of course stopped on the MMapDirectory related ones. The one > with reporting false offsets on random access multi-mmap was > personally known to me, but I never decided to fix it, because the > error message is valid, just a wrong offset reported, which may > prevent easy debugging, but on other hand to have multi-mmap indexes, > the index segment must be larger than 16 GiB and that no longer > happens unless you force merge. Therefor I'd ignore this one. > > The shared arena one looks very relevant and I always had the > "feeling" that something is wrong with them. It was also reported to > me privately by Gianluca Graziadei on/after Apache Community over Code > already (or at least what I got from the report is closely related as > it causes similar symptoms). I don't understand the issue fully, so > maybe Chris Hegarthy can help me fixing it. > > Uwe > > Am 27.10.2026 um 19:42 schrieb Shitij Bhargava: > > Hi all, > > I work in Amazon advertising where we use Lucene for a lot of our ad > candidate retrieval services. We also develop custom codecs and other > customizations for cases where the stock Lucene options aren't > enough. While developing one of them, I asked an AI agent to find > bugs in my POC implementation, and it ended up finding an unreported > bug in Lucene itself. > > I kept going with this approach and it kept finding more unreported > bugs, so I've gone deeper into AI-assisted bug finding with formal > verification and other techniques. As of today the agents have found > 592 bugs in Lucene (and counting) that appear to be unreported in > GitHub or the mailing list. It also found (or already knew from its > training data) nearly 200 bugs that have already been reported, which > I'm not counting here. To avoid noise in these findings, the approach > has each potential bug independently and adversarially verified by a > second model (Claude vs GPT) with a minimal unit test repro and > making sure the behavior is not intended from past discussions in > mailing lists, tests, GitHub discussion & commit/PR history. > > Many of them seem to be minor or low impact (392 low, 196 medium, 4 > high classified by AI), but a few look important. For example: > - After a flush where the only changes are doc-values updates, > openIfChanged returns null and isCurrent() stays true so the update > can be missed: https://github.com/apache/lucene/issues/16900 > - HNSW merge-time graph reuse can leave the entry node with no > neighbours, which drops kNN recall to zero in 10.4.0 and later: > https://shbhar.github.io/lucene-ai-bug-hunt/bugs/LFV-005.html > > I've posted the full running list with some categorization here: > https://shbhar.github.io/lucene-ai-bug-hunt/. I've excluded a few > that might be security sensitive according to AI, will send them > privately to security@ soon. > > I'm working on understanding, triaging and verifying them myself, > then filing issues on GitHub in my own words in line with Lucene's AI > policy (so far I've filed only one). The agents help by preparing > minimal repro tests, diagrams and short explainer videos (not on site > yet) for surrounding context, but understanding and verifying each > bug properly still takes a lot of time, and the community's help > would make a big difference. > > Creating this thread to start a discussion on how to validate and > make these findings actually useful, in particular: > - Could folks help in spot-checking some bugs for areas they might be > familiar with? > - Is it beneficial to track this work in an umbrella github issue? > > Thanks, > Shitij > > -- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: [email protected] > > -- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
