-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clips-executive: release lock if we suddenly become the owner #321
base: master
Are you sure you want to change the base?
Conversation
We encountered a case, where the local mutex fact was saying that another robot held the lock, hence the own mutex request was rejected. After the rejection went through we finally got the update about the request that was sent asynchronously (prior to the requection). Hence the mutex fact changed from (mutex (state LOCKED) (locked-by "other") (request NONE) to (mutex (state LOCKED) (locked-by "us") (request NONE) which is of course not wanted. Co-authored-by: Daniel Swoboda <[email protected]>
Hm at least the example log that you posted shows a different issue:
But at the same time:
So it seems like |
That would make much more sense, i already wondered why the UpdateDescription differs from the doc... So far we always process a trigger by applying the data stored in the fullDocument.
But did anything change or did we always only acted upon outdated data? |
Also, looking into the log again, i find the trigger history for this resource a bit strange:
In particular, i wonder why after a Trigger containing the full Document with |
Looking at the doc of mongocxx change streams, the issue might be the following:
(emphasis mine). So it may be that we get a trigger, but the document that is sent with the trigger already contains data from some subsequent change. |
We encountered a case, where the local mutex fact was saying that
another robot held the lock, hence the own mutex request was rejected.
After the rejection went through we finally got the update about the
request that was sent asynchronously (prior to the requection).
Hence the mutex fact changed from
(mutex (state LOCKED) (locked-by "other") (request NONE)
to
(mutex (state LOCKED) (locked-by "us") (request NONE)
which is of course not wanted.