Approver crashes when trying to approve PO files for disabled templates

[Данило Шеган]

It seems that trying to approve translation files (i.e. PO files) for disabled templates causes rosetta-approve-imports.py script to crash with a traceback like:

Traceback (most recent call last):
  File "/srv/launchpad.net/production/launchpad/cronscripts/rosetta-approve-imports.py", line 32, in ?
    script.run()
  File "/srv/launchpad.net/production/launchpad-rev-8323/lib/lp/services/scripts/base.py", line 244, in run
    self.main()
  File "/srv/launchpad.net/production/launchpad/cronscripts/rosetta-approve-imports.py", line 23, in main
    process.run()
  File "/srv/launchpad.net/production/launchpad-rev-8323/lib/lp/translations/scripts/po_import.py", line 222, in run
    if translation_import_queue.executeOptimisticApprovals(self.ztm):
  File "/srv/launchpad.net/production/launchpad-rev-8323/lib/lp/translations/model/translationimportqueue.py", line 1079, in executeOptimisticApprovals
    guess = entry.getGuessedPOFile()
  File "/srv/launchpad.net/production/launchpad-rev-8323/lib/lp/translations/model/translationimportqueue.py", line 458, in getGuessedPOFile
    sourcepackagename=self.potemplate.sourcepackagename)
  File "/srv/launchpad.net/production/launchpad-rev-8323/lib/lp/translations/model/translationimportqueue.py", line 354, in _get_pofile_from_language
    potemplate_subset = potemplateset.getSubset(
  File "/srv/launchpad.net/production/launchpad-rev-8323/lib/lp/translations/model/potemplate.py", line 1163, in getSubset
    iscurrent=iscurrent)
  File "/srv/launchpad.net/production/launchpad-rev-8323/lib/lp/translations/model/potemplate.py", line 953, in __init__
    assert productseries is not None or distroseries is not None, (
AssertionError: Either productseries or distroseries must be not None.

We are still investigating (seen problems in https://translations.edge.launchpad.net/enlightenment/trunk/+pots/iiirk/, I've blocked translation files for now).

[Jeroen T. Vermeulen (jtv)]

This happens if TranslationImportQueueEntry._get_pofile_from_language fails to find a current template with the translation domain it's looking for in the productseries, distroseries, and sourcepackagename as stored in the queue entry... in the case where it already _does_ know the template, but the template is disabled and is for a productseries, not for a package.

In that situation, _get_pofile_from_language tries again with just the distroseries as stored in the queue entry, without the sourcepackagename... *and* without the productseries because this kind of matching is only supposed to happen with distros, not with products. So it only passes the entry's distroseries to the templatesubset. But if the entry is for a productseries, that'll be None and this assertion triggers. AFAICS, AIUI, IMHO, YMMV, IANAL, ISTM TANJ.

How could this ever have worked then? I think it's because getGuessedPOFile only gets to the fatal _get_pofile_from_language call if it already has the right template, and produces a good guess as to the language.

At that point it seems to be all set. But _get_pofile_from_language, instead of using the entry's potemplate if there is one, tries again to look for it--and fails because the template is not current.

There are three things we can do about this.

1. Make _get_pofile_from_language use an existing potemplate if the entry has one (even if it's disabled). I think that's the right thing to do in cases where it's already clear what template the entry belongs to anyway. It looks to me as if the method was written on the assumption that the entry is not attached to a template, and later we started calling it in other cases as well.

2. Mark entries that are definitely attached to a disabled template as Deleted. Seems the right thing to do, though I don't know for certain that it won't upset any existing use cases.

3. Skip the second-try POTemplate search if the template is for a productseries rather than a package.

And maybe we should do all three. But for a minimal fix I'd go with 3.

[Jeroen T. Vermeulen (jtv)]

See the attached branch.

[Jeroen T. Vermeulen (jtv)]

Fixed in devel 9060.

[Jeroen T. Vermeulen (jtv)]

Fix is in db-devel 8359