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

Description

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.

Testing

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.

Environment

None

Status

Assignee

ticking instant

Reporter

Sarken

Roadmap

Challenges

Priority

Medium

Affects versions

Fix versions

None

Components

BackEnd

Difficulty

Hard

Required Access Level

None

Milestone

Internal 0.9
Configure