Gift Exchange: Possible for assignment generation to create multiple assignments for a single user


The problem

sarken Oct 7th at 19:58
I'm doing a smoke test of gift exchanges following the Ruby update and I wanted to double check that this is normal. I ran matching (set to random) on an exchange, and the generated assignments included two for the same giver/recipient combo.

ticking instant (AO3 Contributor) 23:26
That definitely shouldn't happen. There are a whole bunch of checks to try to make sure that no one has more than one assignment (either as a recipient or a giver). (edited)

The ChallengeSignup fields assigned_as_request and assigned_as_offer are supposed to be set whenever an assignment is created, and there are a lot of lines of the form next if request_signup.assigned_as_request and similar.

ticking instant (AO3 Contributor) 23:40
(That said, there's a chance that it might not be caused by the Ruby update, since I think stale data could also produce behavior like that. Have you checked that variable for measuring replication health recently? I just searched chat and I think the command was SHOW STATUS LIKE 'wsrep_local_recv_queue_avg';.)

ticking instant (AO3 Contributor) 17:13
It might be a matter of degree, if it is stale data. There were issues before where the assigned_as_request value was available when the assignment was not, because they were committed in different transactions. This issue would arise if the new value of assigned_as_request and the new assignment were unavailable. So if wsrep_local_recv_queue_avg has been trending upwards, this might be the next stage of it: accidentally double-assigning users.

(In theory, it could manifest as two different assignments for the same user, as well.)

ticking instant (AO3 Contributor) 22:41
A couple years back, I was playing around with rewriting the assignment generation code to (a) try to reduce the number of database queries, and (b) return a maximum matching instead of a maximal matching. One of the side effects of having fewer queries is that it ought to be less susceptible to stale data issues. I can try to dust off the code, if you'd like.

tl;dr: Sometimes one user gets multiple assignments in a gift exchange.


This is a stale data issue, so it's not reproducible at will. Create a gift exchange, get multiple sign-ups, run matching, and ensure everything looks normal and there are no instances of duplicate assignments. Repeat a few times.


November 1, 2019, 6:27 PM

If you want a consistent database view you need to start a transaction at the beginning of the process and commit at the end.


ticking instant







Affects versions

Fix versions







Internal 0.9