Potential payday race condition

[coderanger]

If a payday is interrupted and then resumed later, but in the gap someone opted-in to gittip it will produce inconsistencies. If I'm reading this code right, https://github.com/gittip/www.gittip.com/blob/master/gittip/models/participant.py#L661 should be checking if the claimed_time <= for_payday (read: they claimed their account before this payday started).

[coderanger]

I'm also somewhat confused by genparticipants being called three times in the run() method, but I'm not sure there's an actual race condition there or just inefficiency.

[chadwhitacre]

@zwn Can you say more about how this relates to #1428? Or otherwise review this ticket? :-)

[zbynekwinkler]

Sorry, it does not relate. And @coderanger is right, genparticipants is not idempotent and it should be if we hope to resume the payday after an error.

[chadwhitacre]

My recollection is that I decided that genparticipants not being idempotent wasn't a big deal. I recall noticing that a payday rerun (which is not theoretical, it does happen occasionally) would be subtly different than the first run, but in a way that was acceptable. I guess I didn't document that in the comments?

[zbynekwinkler]

I wasn't super scared reading the report either. But still, it would be better to have it be idempotent.

[chadwhitacre]

Cool, I've marked this ★★☆.

[Changaco]

Payday has been rewritten (#2508).