-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AttributeError: 'NoneType' object has no attribute 'get_newest_date' #46
Comments
hmpf. for some reason my comment did not show up here.. might have to do with me being in a train. anyhow: I can't reproduce this one, there must be something special with a particular thread in your initial search result. |
|
This issue is still preventing me from using alot. I cannot figure out how to view the thread that is causing problems. I'm running 'notmuch show ' and it's not displaying anything. Any ideas? |
Ah, I'm starting to track this issue down now... |
Ok, so the core of the problem here is with emails that have timestamps that are in the future.
In notmuch.vim, this message timestamp is displayed as (the future). |
i knew the problem would solve itselve if we wait long enough :) Regarding the timestamp issue: Could you provide such a problematic timestamp?
but on my system (ubuntu 11.04) i get
Seemingly i can go as high up as the year 10000 before i get these errors.
So: a fix should look like this:
This way we won't have to hardcode that value. moreover, the threadline widget could test for exactly |
datetime doesnt seem to use time.localtime, as this works perfectly well here:
|
|
Ok, so my last traceback is caused by me adding a 'logging.exception' when the Thread.init fails, so that is probably why you were confused. When running 'notmuch show thread:ID', the date in the header is as follows: The following patch works around the issue, but I have a feeling this is a bug somewhere else. --- a/alot/db.py
+++ b/alot/db.py
@@ -204,8 +204,14 @@ class Thread(object):
self._authors = thread.get_authors()
self._subject = thread.get_subject()
ts = thread.get_oldest_date()
- self._oldest_date = datetime.fromtimestamp(ts)
- self._newest_date = datetime.fromtimestamp(thread.get_newest_date())
+ try:
+ self._oldest_date = datetime.fromtimestamp(ts)
+ except ValueError: # year is out of range
+ self._oldest_date = datetime.min
+ try:
+ self._newest_date = datetime.fromtimestamp(thread.get_newest_date())
+ except ValueError: # year is out of range
+ self._newest_date = datetime.max
self._tags = set([t for t in thread.get_tags()])
self._messages = {} # this maps messages to its children
self._toplevel_messages = []
diff --git a/alot/message.py b/alot/message.py
index e00d62d..2fb41e0 100644
--- a/alot/message.py
+++ b/alot/message.py
@@ -43,7 +43,10 @@ class Message(object):
self._id = msg.get_message_id()
self._thread_id = msg.get_thread_id()
self._thread = thread
- self._datetime = datetime.fromtimestamp(msg.get_date())
+ try:
+ self._datetime = datetime.fromtimestamp(msg.get_date())
+ except ValueError: # year is out of range
+ self._datetime = datetime.max
self._filename = msg.get_filename()
self._from = msg.get_header('From')
self._email = None # will be read upon first use |
@logging.exception: ahyes, ok makes sense, thx. quick question: does fromtimestamp also throw a ValueError if the timestamp is below datetime.min ? if so, Unfortunately, this might well be an error in the notmuch lib. One more thing: could you have a look at the source of that message and post the date-header here? Is it only one single mail that causes the problem? |
oh wait: |
Yup, it's definitely not valid, and the spam checker headers in that message also mention that it is invalid. |
ok: i'd favor something like this:
Moreover we must take some care when designing the new™ Messagelist buffer that will replace threadbuffer It would be cool if we had some sort of validity checker for header (is there something in stdlib?). Then we could I don't have much time atm, but will hack on a fix here soon if you don't beat me to it :) |
found the time :) this should fix the issue for you. Strangely, I still cant reproduce it as a call to |
I started with a fresh setup with the latest notmuch & alot, and now I'm getting this exception.
The text was updated successfully, but these errors were encountered: