launchpad.bug_info() tries to return None, explodes

[Graham Binns]

We're seeing tracebacks from the Tahoe Trac instance when checkwatches is attempting to update a bug (OOPS-1059CCW1888):

Traceback (most recent call last):
  Module canonical.launchpad.scripts.checkwatches, line 210, in updateBugTrackers
    self.updateBugTracker(bug_tracker)
  Module canonical.launchpad.scripts.checkwatches, line 300, in updateBugTracker
    self.updateBugWatches(remotesystem, bug_watches_to_update)
  Module canonical.launchpad.scripts.checkwatches, line 408, in updateBugWatches
    remotesystem.initializeRemoteBugDB(remote_ids_to_check)
  Module canonical.launchpad.components.externalbugtracker.trac, line 275, in decorator
    return func(self, *args, **kwargs)
  Module canonical.launchpad.components.externalbugtracker.trac, line 316, in initializeRemoteBugDB
    time_snapshot, remote_bugs = self._server.launchpad.bug_info(
  Module xmlrpclib, line 1096, in __call__
    return self.__send(self.__name, args)
  Module xmlrpclib, line 1383, in __request
    verbose=self.__verbose
  Module canonical.launchpad.components.externalbugtracker.xmlrpc, line 98, in request
    response = self._parse_response(self.opener.open(request), None)
  Module xmlrpclib, line 1286, in _parse_response
    return u.close()
  Module xmlrpclib, line 744, in close
    raise Fault(**self._stack[0])
Fault: <Fault 2: "'cannot marshal None unless allow_none is enabled' while executing 'launchpad.bug_info()'">

This seems to indicate that launchpad.bug_info() is trying to return None when it shouldn't.

[Tim Hatch (timhatch)]

I could use a little more information in trying to track this down. Do you have as part of the oops, exactly what the parameters were (all would be helpful, but especialy level, and buglist or the offset/limit pair).

[Graham Binns (gmb)]

> I could use a little more information in trying to track this down. Do
> you have as part of the oops, exactly what the parameters were (all
> would be helpful, but especialy level, and buglist or the offset/limit
> pair).

Irritatingly, no. I'm investigating further and will look at the logs.

[Tim Hatch (timhatch)]

Has this continued to cause OOPSes?

[Graham Binns (gmb)]

On Sat, Dec 13, 2008 at 05:22:33PM -0000, Tim Hatch wrote:
> Has this continued to cause OOPSes?

I've seen nothing in the logs recently to suggest that it has. I'm going
to mark this as Invalid for the time being since it hasn't been
reproduced and I can't find sufficient information anywhere to reproduce
it in a development environment. If we find a way to reproduce it or it
reoccurs we can always reopen this bug.

 status invalid

[Graham Binns (gmb)]

This is still happening on the Pidgin Trac, at least.

[Tim Hatch (timhatch)]

Aha! Based on the two bugs listed on Pidgin with the launchpad bug field set, found the issue. It was unset fields like component, milestone, etc. They will now be empty strings if unset.

Fix committed, and release 0.1.2-2 made. I signed it myself (F1B3E047)... Graham, would you rather have your key on it?

[Graham Binns (gmb)]

2009/2/17 Tim Hatch <email address hidden>:
> Aha! Based on the two bugs listed on Pidgin with the launchpad bug field
> set, found the issue. It was unset fields like component, milestone,
> etc. They will now be empty strings if unset.

Thanks for finding and fixing this, Tim :).

> Fix committed, and release 0.1.2-2 made. I signed it myself
> (F1B3E047)... Graham, would you rather have your key on it?

No, that's fine.Thank you.