I've been amazed over the years this has never been fixed -- it's very hard not to make jokes about the standard lifestyle of open-source programmers, that they don't consider this a priority (note: that's a joke, I consider myself an open-source programmer. I would hope that's obvious, but someone just bothered to sent me a mean anonymous message)
Indeed most of the time I already know the exact word I'm looking for; and most of the time I get non-exact hits making it so much more difficult to find the actual message.
Perhaps there could be an option to disable stemming completely from the inverted index, which would be probably easier to implement than a post-search filter (which in itself doesn't sound very complicated..).
But of course, it's open source, anyone could contribute :D.
The search in thunderbird is terrible compared to what we are used to today. Same for k9 (now thunderbird for android?).
Not only is the UX a horror, its results rely on all sorts of technicalities. I, as a software engineer, can understand that a mail has to be downloaded in entirety locally in order to have it indexed and then show up in the results. And I understand that sub-sub directories aren't really a thing in IMAP, so searching this-dir-and-everything below is hard/impossible and so on.
But mostly the search algorithms are poor. So much so, that I often rely on (rip)grep to find mails. Or in a few occasions wrote a quick bash/python horror to push all my mail into a meilisearch instance and then use this search engine to get the lists and filters that I would expect thunderbird to have.
Yes. It's open source. So "go fix it" is a proper reply. But that doesn't make a complaint about the state of the search feature invalid.
I don't know why you're getting downvoted for this. That seems like a pretty frustrating bug when generalised to other word stems. It's also pretty standard to prioritise exact matches when ordering search results so, again, frustrating.
One of my biggest bugbears with Microsoft Outlook has always been that its search function is terrible. If you can't find an email then it may as well not exist, and that's been a real problem on a regular basis during my career - particularly latterly when I was in leadership and necessarily lived in my email and calendar.
It's disappointing that Thunderbird has similar issues with such a fundamental function.
That is annoying. I wish I could advance search or better, use regex. Luckily there are plugins.
Worse though, in Apple Mail I'll search an email address because I got an email earlier in the week and the first thing it'll show me is an email I got from that person 3 years ago with the correct result a few down. I really need a better email client for my phone...
The filter/search feature in Thunderbird does not appear to have a way to search for exact matches. You want exact matches. First, identify if it can do exact matches and if so, expose to the user. Else, who wants to touch that code?
Nitpick: not all bugs have to be reproducible to be taken seriously. Defensive programming, and adding extra logging could be a mitigation to avoid future problems, or to help fixing them in the future.
Imagine you're writing trading software, you have an algo go haywire and it machine guns the whole order book, and then you refuse to put a "max order size" outside of the algo to stop it from happening again because you can't figure out why it happened in the first place.
Try telling a regulator or your boss that was your reasoning.
How many one-off band aids do you think should be applied for rare, never reproduced problems before you slap a “100% safe” label on it and ship it with the confidence of a bloated, cruft-ridden job well done?
Are you arguing in bad faith, or do you just not have any practical experience dealing with complex systems?
Even if the bug can't be reproduced, on the basis of multiple user reports the first step absolutely should be to add some assertions and logging around email deletion.
The point is not to give it a "100% safe" label, the point is to start narrowing down possible root causes. If the problem recurs again, you'll have assertions ruling out certain possible culprit code paths as well as logs displaying the values of relevant variables.
Kinda off topic, but I've been searching for good introduction and best practises for defensive programming, but never really found much. Any recommendations?
I don’t know of any real posts on it, it just ends up being kind of a “assume it’ll go wrong,” then figure out how you know something has gone wrong and track it down. Your starting point is, after an issue is reported, add a load of logs around places that seem like candidates for the flow. Over time, you get a sense of where things can break and you add that telemetry ahead of time.
I feel like this is sort of like reading a book to get better at self defense. Yeah, you'll probably pick up a few interesting things that may be of questionable use. But when you train in martial arts, you often get to go through the motions and put the moves into practice. Even then "real" fights will feel quite different and a lot of the stuff you've learned will likely fly out the window. If you've been in real fights a lot, you've begun to internalize your training and your moves become more like instinct. It's quite difficult to go from book knowledge to instinct without getting beat up a lot in between I think. The real valuable lessons come from building something that breaks and getting to fix it yourself.
This issue comes up in my role a lot, where I am often dealing with various environmental conditions and human factors, plus multiple integration points between various software and hardware systems.
The answer is that you keep working at it iteratively using a combination of logging, reporting, and defensive programming to systematically narrow down the possible causes. Sometimes you never arrive at a true root cause, but you get close enough that you can mitigate the problem and finally close the ticket out. At the end of the day, the customer/user doesn't care as long as it works.
However, what will really piss them off is telling them your hands are tied until they can reliably reproduce the issue for you. It's important they understand that you are working on it, and typically they will go out of their way to help solve the problem when they feel taken care of.
Why do you think it needs reproducible steps? It is obvious that the bug is still active, so in a way it is reproducible, just not in a systematic way.
This happens more often, for example when many services work together in an asynchronous way, and in some very rare situation, unwanted behavior occurs. To fix that, it is often easier to reason through the entire process, and to identify weak spots. It might even be a good idea to switch to a different paradigm to avoid certain bugs altogether.
For this particular bug, I would start by reading a lot, and ensurong that the bug is indeed not easily reproducible (by trying to make it reproducible of course). If that fails, I would continue to think about root causes for the bug, and possible workarounds that would work in theory. Then I would try to estimate the amount of work required, and the risk of breaking other things, and report that to those who like to decide on further actions.
And of course, as I know very little about the inner workings of ThunderBird, I would simply ask ChatGPT o3 or similar for advice. It comes up with a plan that seems reasonable.
No it doesn't. If I waited every time for obscure production issue to be reproduced in lower envs I would be fired... many times for clear and obvious incompetence.
Sometimes, you can add some additional steps, logging, change behavior in corner case a bit, either to get more understanding next time it happens or even mitigate it. Sometimes, you have plenty of tools and ways to act. In my experience, that sometimes is basically always if one cares enough.
What developers should do on such a critical and long standing issue is to offer an extension that victims can install to volunteer to track the bug. So they can click a button when things are fine to take a snapshot, and click another one when they encounter it.
If it was me running the project there's enough information in that thread to piece together an exploratory testing plan around the issue that might allow us to isolate it, and I'd set aside some time for the team to do that.
Whilst obviously not lethal, this Thunderbird bug sort of reminds me of the Therac-25 incidents in the 1980s. Very occasionally the machine would give patients massive overdoses of radiation. This bug wasn't easy to reproduce (thankfully) and turned out to be due to a race condition.
But of course, you can't find a problem if you don't investigate, and if it's a serious problem that's been documented then, as engineers, we can't just hide behind non-reproducibility as if it's some sort of magic shield. We have a responsibility to investigate and isolate the problem ourselves. If we don't do that we are effectively washing our hands of our own creations.
Not only that. Often mitigations can be placed even if the actual bug cannot be reproduced. Like many others in the thread suggested.
I've encountered several impossible to reproduced bugs in the past. And what I (or my team) would then do, is re-architecture (refactor) some pieces of software so that we could reproduce it. Like e.g. better logging, specialized layers/adapters/services, simpler logic, and -above all- better testability.
I explicitly do not, which is why my first response spells out that it’s hard to reproduce a bug when all your data is gone. If it is the case that the bug can be reproduced without user data (as suggested by the person I responded to, not me), then the developers should be able to do that better than users can.
You’re assuming users affected by this bug have control over the VM running their mail server. I won’t argue that it can’t be done, but it’s probably harder than we think.
I've been amazed over the years this has never been fixed -- it's very hard not to make jokes about the standard lifestyle of open-source programmers, that they don't consider this a priority (note: that's a joke, I consider myself an open-source programmer. I would hope that's obvious, but someone just bothered to sent me a mean anonymous message)