@mattia any ideas on this? I suppose as a worst case, I could run it again without the open tickets flag and then manually open the ones that were missed.

I re-ran without opening tickets and the resulting CSV file looks reasonable (assuming the problematic account didn't just happen to show activity in the interim):

bmasney,NONE,b***y@redhat.com
iivanov,NONE,i***@gmail.com
tanguy,NONE,e***y@gmail.com

(addresses manually masked)

So, in a second run the missing emails were retrieved correctly?
The email list for a user is fetched during _check_maillist_activity() from fasclient. If an empty list is returned, the script will not fail until opening the tickets in pagure, so I suppose we should error out earlier, because an empty list will simply bypass checks on mailing lists and bugzilla.

We should also set up a way to resume a failing run... manually open ~300 tickets from a csv file is not acceptable!
I think we can fetch open tickets at the start of step_one like we do in step_two and filter out users with open tickets. I can write down something in some days, so you can avoid to open tickets manually...

So, in a second run the missing emails were retrieved correctly?

It seems so.

The email list for a user is fetched during _check_maillist_activity() from fasclient. If an empty list is returned, the script will not fail until opening the tickets in pagure, so I suppose we should error out earlier, because an empty list will simply bypass checks on mailing lists and bugzilla.

I guess the question is: do we want to ignore that case or set it to something like "UNKNOWN" when it fails? I think the second option is better. If, for some reason, we never get an address back from FAS for that person, they'll never get marked as inactive. If we keep them on the list, the worst case is they have to reply to the ticket saying "I'm still here!"

Of course, that might lead to errors in later checks, which we'd then have to handle, but maybe that's a bug not a feature. :-)

We should also set up a way to resume a failing run... manually open ~300 tickets from a csv file is not acceptable!
I think we can fetch open tickets at the start of step_one like we do in step_two and filter out users with open tickets. I can write down something in some days, so you can avoid to open tickets manually...

Hm. That could work, but I worry it could end up being fragile in ways we don't expect. My first thought was "what if a ticket was closed because the person already responded that they're still active?" but of course then they'd have Pagure activity and wouldn't be flagged again.

What about this? The script can optionally take in a CSV file from a previous run and it will skip checking users listed in it. If the CSV file has a Pagure ticket listed, it skips opening the ticket. If Pagure ticket is "NONE", then it opens the ticket (but does not run the activity checks)?

This would make a re-run faster and would reduce the calls to Pagure, which is friendlier. Of course, that might make the logic more complicated, so just doing the check for if a ticket exists in the CSV file or not would be sufficient.

I think what I'll do for the time being is trim the CSV file to only include ones that didn't get a ticket created on the first pass. Then I'll create a separate script that's essentially just the ticket-opening code from find_inactive_packagers.py to open the tickets. This way I don't have to do them manually.

This is fixed in #1444 although it is really strange that FAS could return no emails for a user...

I'll open another ticket to have some sort of save and resume mechanism.