Duplicate entry 'x-y-t' for key 1 query: INSERT INTO user_relationships

Sorry if this is somehow a dup. I took a look through the bug list and didn't see anything.

So, I purposely tested a scenario to see what happens. I logged in as user X and requested to be a Teammate of User Y. Then, I logged in as user Y and, without accepting the pending Teammate request from user X, requested to be a Teammate of User X. So, basically, if users X & Y submitted the same Teammate request before Y accepts the first request then the database ends up with two of the same pending relationship request under two different request id's (rid).

When either of the two pending requests is finally accepted the module tries to automatically add the other side of the relationship. However, since the other side of the relationship already exists in a pending request (of a different rid) it generates a duplicate key 1 (i.e. the "relationship" key) in the database. This leaves you with one half of the relationship accepted and the other half never created because of the key failure.

Error Message
Duplicate entry '1-620-4' for key 1 query: INSERT INTO user_relationships (rid, requester_id, requestee_id, rtid, approved, created_at, updated_at) VALUES (4, 620, 1, 4, 1, 1201573808, 1201574071), (4, 1, 620, 4, 1, 1201573808, 1201574071)

Now, I also figure if the other user were to later accept the other pending request then it would approve that half of the request and generate the inverse duplicate key error. So, in the example above, it would try to duplicate 620-1-4, which already exists as an approved request from the first relationship approval.

This means if both users submitted the same request and both later approved the other's request then you could have two approved requests for a two-way relationship, only they would have two different request id's (rid).

Sorry if I'm making false assumptions, but I figured there should only be one (rid) per relationship. I suppose the proactive way to avoid this would be to prevent the second user from making a relationship request if the user on the receiving end already has a pending request for that relationship. Or, a reactive approach (probably not as good), allow both users to make the same request, but always check that the automatically created reciprocal relationship isn't already in the database under a different rid. If so, it would be deleted before it was automatically added by the code.