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

[Alys]

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!

[Alys]

shanaqui says there are more reports of quest invitation problems now so this might be a code bug after all. My laptop is broken so I haven't investigated.

[Alys]

BTW if this is caused by one update failing while the other succeeds then the opposite case to what's reported here is basically the same problem (user document being updated; party document not).

[SabreCat]

Bumping up the priority here because of how oddly often it's occurring (and thus chewing up user support time)...

[veeeeeee]

We think this is still happening, but could someone confirm?

[Alys]

It will still be happening because it's still possible for one of the two database update commands to fail while the other one succeeds.

[paglias]

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!

[shivamAmrutia]

hello I would like to help if this issue is still open. I understand that we need to implement mongoDB transactions and I think I can manage that. I am new to open source so I might require some guidance. Please let me know if I can work on this issue.