ZeroDivisionError on launchpad.net/~linaro/+upcomingwork

Here's the error:

Traceback (most recent call last):
  Module zope.publisher.publish, line 134, in publish
    result = publication.callObject(request, obj)
  Module lp.services.webapp.publication, line 499, in callObject
    return mapply(ob, request.getPositionalArguments(), request)
  Module zope.publisher.publish, line 109, in mapply
    return debug_call(obj, args)
   - __traceback_info__: <security proxied zope.browserpage.metaconfigure.SimpleViewClass from /srv/launchpad.net/production/launchpad-rev-15259/lib/lp/registry/browser/../templates/person-upcomingwork.pt instance at 0x2b4b703946d0>
  Module zope.publisher.publish, line 115, in debug_call
    return obj(*args)
  Module lp.services.webapp.publisher, line 395, in __call__
    self.initialize()
  Module lp.registry.browser.person, line 4469, in initialize
    100.0 * total_done / float(total_items))
ZeroDivisionError: float division

Having trouble recreating this in a test or just a local dev instance. It is clear that we could avoid the issue by checking if total_items was 0 and not doing the divide, but it should never be 0 in the first place.

https://staging.launchpad.net/~linaro/+upcomingwork works (currently) so I can't gather extra information from there.

A review of the code seems to show that total_items will always be at least 1, since they are array lengths and those arrays are only created just before the first item is put in them (there is no way out of the function (getWorkItemsDueBefore) that creates those arrays where they can be empty.

Clearly I can just protect the section of code that has the divide by 0 in, probably something like the code below, but with no test and no logical reason for this happening, it feels like the bug lies elsewhere...

class PersonUpcomingWorkView(LaunchpadView):
    """This view displays work items and bugtasks that are due within 60 days
    and are assigned to a person (or participants of of a team).
    """

    # We'll show bugs and work items targeted to milestones with a due date up
    # to DAYS from now.
    DAYS = 180

    def initialize(self):
        super(PersonUpcomingWorkView, self).initialize()
        self.workitem_counts = {}
        self.bugtask_counts = {}
        self.milestones_per_date = {}
        self.progress_per_date = {}
        for date, containers in self.work_item_containers:
            total_items = 0
            total_done = 0
            milestones = set()
            self.bugtask_counts[date] = 0
            self.workitem_counts[date] = 0
            for container in containers:
                total_items += len(container.items)
                if total_items == 0:
                    continue

                total_done += len(container.done_items)
                if isinstance(container, AggregatedBugsContainer):
                    self.bugtask_counts[date] += len(container.items)
                else:
                    self.workitem_counts[date] += len(container.items)
                for item in container.items:
                    milestones.add(item.milestone)
            self.milestones_per_date[date] = sorted(
                milestones, key=attrgetter('displayname'))
            self.progress_per_date[date] = '{0:.0f}'.format(
                100.0 * total_done / float(total_items))

https://code.launchpad.net/~dooferlad/launchpad/postponed-is-done/+merge/106611 contains code that will prevent the x/0 problem from being evident (it just sets the % complete to 0 since an infinitely wide progress bar didn't appeal), but doesn't address the problem that the code that was crashing, shouldn't have got into that state in the first place.

I'd rather if we don't hide the OOPS because it will make it harder to find the root cause (and that's what we've got to do).

Since I was editing the relevant code I thought it reasonable to protect the divide. I hope that what will happen is we will now get a page that renders that we can use to trace what data is being used, which will allow us to track down the problem. I expect we will see something odd, but with any luck not an OOPS.

Fixed in stable r15300 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/15300>.

QAd on https://qastaging.launchpad.net/~linaro/+upcomingwork and https://blueprints.qastaging.launchpad.net/linaro-infrastructure-misc/+spec/linaro-infrastructure-stakeholder-process