quest invitation partial failure: RSVPNeeded still true after invitation accepted in party's data, or vice versa

When a player accepts a quest invitation, it's possible for their acceptance to be recorded in the party (e.g., see the true value in the party data below) but for the invitation to not be removed from the player's own party object (see the RSVPNeeded value below - it should have been set to false when the invitation was accepted).

This won't be from a code bug as such, but from one update being saved to the database while the other is not.

I can think of a couple of options for fixing this:

1. A fix: Adjust the current code for updating the party's document and updating the player's document so that it checks to see if both updates were done, and if either or both fails, it repeats them until they're successful.
2. A workaround: When this situation occurs, the user typically tries to accept the invitation again. That fails with the questAlreadyAccepted error message because the code recognises that there's no pending invitation state in the party's data. When that situation occurs, the code could check to see if the user's RSVPNeeded value is still true and set it to false and then not report the error to the user. If the RSVPNeeded value was already false, then we'd throw the error as usual because then the user really is trying to do something that should no longer be possible for them to do. Something similar would be needed for the case where the user is trying to reject the invitation.

The first option is more "correct" in that it fixes the problem when it occurs. The second option might be easier to code.

I'll leave this as suggestion-discussion for a few days to see if anyone can suggest better ideas.

{
    "_id": "3cac8ad0-62ca-4c5b-8c1d-30dca143e38a",
    "quest": {
        "progress": {
            "collect": {}
        },
        "active": false,
        "members": {
            "62da043c-80a8-4793-affb-7274a8b82cfa": true,
            etc
        },
        "extra": {},
        "key": "goldenknight3",
        "leader": "..."
    }
}

{
    "_id": "62da043c-80a8-4793-affb-7274a8b82cfa",
    "party": {
        "quest": {
            "progress": {
                "up": 6.535623919649389,
                "down": 0,
                "collectedItems": 4,
                "collect": {}
            },
            "RSVPNeeded": true,
            "key": "goldenknight3",
            "completed": ""
        },
        "order": "level",
        "orderAscending": "ascending",
        "_id": "3cac8ad0-62ca-4c5b-8c1d-30dca143e38a"
    },
}

---

With PR #12335 the Habitica codebase has been updated to support MongoDB 4.2 and transactions making it possible to fix this issue.

Transactions allow operations on multiple documents to be executed ensuring that either all of them are executed correctly or none, making it possible to fix this issue.

An example on using transactions can be found at https://mongoosejs.com/docs/transactions.html while more info at https://docs.mongodb.com/manual/core/transactions/. If you want to work on this issue and have any question please leave a comment!