[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#926455: mail_autoremovals: incorrect version number in email warning



Hi,

On Mon, Aug 17, 2020 at 10:33:09AM +0200, Matthijs Kooijman wrote:
> Looking at the mailer script [1], it seems it tracks the most recent autorm
> email notification timestamp (to make sure to send out a notification only
> every 20 days) for each package version separately. So this makes me suspect
> that when a package migrates to testing that is subject to autorm:
> 
>  1 the new version is first inserted into the `testing_autoremovals` table
>  2 the mail_autoremovals.pl script runs, sees this new version for which no
>    notification was sent before, so immediately sends out a mail notification
>  3 the autorm status is cleared for the package, because the fixing version was
>    migrated to testing
> 
> I'm not quite sure where all this is orchestrated, so I couldn't check this in
> any code (other than the mail_autoremovals.pl code). Also, I can't remember
> seeing this behaviour before for packages where autorm was cleared by an
> upload, so I suspect that there might be a race condition between two processes
> here.
> 
> Regardless, it seems that the new, fixing, version should *never* end up in the
> `testing_autoremovals` table, since that version is really never subject to
> autorm AFAICS. So if my analysis is correct, maybe that's something that can be
> fixed?

The main issue is that the 'affects_testing' field in the udd bugs table
doesn't provide information about the version that was used to decide if the
bug affects testing or not. When a new version migrates to testing, it can
take some time for this information to be recalculated based on the new
version. Until that is done, this information is wrong. The autoremoval info
will be calculated based on that. The correct way to solve this would be to
somehow include version information in the importer for bug information.

To work around the mailing problem, I changes the autoremoval importer to
reset the 'first_seen' timestamp when the version changes, and I changed the
mail script to avoid sending mail on the first day. When a new version
migrates, this should prevent a mail from being sent in the first 24 hours.
By the time those are passed, the bug status and the autoremoval info should
be up-to-date.

Please let me know if this doesn't solve the mail issue.

Thanks,

Ivo


Reply to: