[Systers-dev] The "last" bug (for this cycle, I hope)

[Robin Jeffries]

Kanika Vats, I think you are the one who can help here.

I'm trying to debug the one bug we found in the latest testing cycle.  I
think it is in the ORM code, and I don't know enough about that to change
anything.

The bug is 483128  (Anna found it)

The symptom is that when you send mail to something like
systers-dev+foo at abiwt.org <systers-dev%2Bfoo at abiwt.org> when there is no
conversation named foo, you get a traceback (and you don't get the error
email that you should receive because it barfs before it gets that far).
 Here it is

Nov 22 17:02:16 2009 (5240) Traceback (most recent call last):
  File "/usr/local/mailman/Mailman/Queue/Runner.py", line 114, in _oneloop
    self._onefile(msg, msgdata)
  File "/usr/local/mailman/Mailman/Queue/Runner.py", line 185, in _onefile
    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 130, in
_dispose
    more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 153, in
_dopipeline
    sys.modules[modname].process(mlist, msg, msgdata)
  File "/usr/local/mailman/Mailman/Handlers/Dlists.py", line 47, in process
    (thread_id, thread_name) = thread.threadIDandName(thread_reference)
  File "/usr/local/mailman/Mailman/DlistUtils.py", line 53, in inner
    result = f(self,*args)
  File "/usr/local/mailman/Mailman/DlistUtils.py", line 484, in
threadIDandName
    thread_id = thread_id[0]#to convert a list to int
IndexError: list index out of range


This is in the function to get either a thread id from a name or a thread
name from an id (in this case, the former, but it should fail).

after the database call to get all threads with this name, we have
 thread_id = [(thread.thread_id) for thread in result]

I gather that's some sort of guard against there being multiple thread_ids
for that name, as well as casting the result from the DB as a list of
thread_id s).  The next line is:
  thread_id = thread_id[0]#to convert a list to int

Which takes the first item out of that (hopefully one item) list.

That's where it barfs, because the list returned is (I assume) empty.

The next line (other than some DEBUG_MODE stuff) is a test for the null
result
if thread_id == None:

I believe that this has to come BEFORE the attempt to pull out the first
thread_id, perhaps before the cast.  But I don't understand the ORM code
well enough to be 100% sure of this.  Kanika Vats, can you take a look and
make the change in your branch?

One thing that might be a clue. The DEBUG_MODE statements at lines 477 and
480 are not being executed.  I don't see how you can get to line 484 without
going through line 480, but perhaps I'm not understanding the code
correctly.  (There are other DEBUG_MODE statements being output to the info
log, so I know that DEBUG_MODE==1)

This is all that is standing between us and getting your code working on
systers.  (well, we will need to do some more testing).

Let me know if I'm the one who is confused.  This file has changed so much
since I last looked at it, that I may well not be understanding all the
things that are going on.

Robin