You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @mike-marcacci, this appears to be a flavor of request you have received before (i.e. more specific error messaging) but I didn't see this specific request already. Let me know if this is a duplicate or something you wouldn't want to introduce!
For my use case, I am acquiring two locks at the same time before running an operation. The current version of the library just returns a generic message The operation was applied to: 0 of the 2 requested resources. in the vote data when a server fails to acquire the locks. This generic message makes it impossible at the time of the error to know which of the two locks could not be acquired. Knowing which lock was already acquired is useful for better tracking as in my case contention on the first lock is more expected, while contention on the second lock should be rare and thus a useful metric to alert on.
I believe that this change could be implemented with a small tweak to the acquire script, and a larger change to the _attemptOperationOnClient functions error handling, but I didn't want to create a PR for this change if there was no appetite for it.
The text was updated successfully, but these errors were encountered:
Hi @mike-marcacci, this appears to be a flavor of request you have received before (i.e. more specific error messaging) but I didn't see this specific request already. Let me know if this is a duplicate or something you wouldn't want to introduce!
For my use case, I am acquiring two locks at the same time before running an operation. The current version of the library just returns a generic message
The operation was applied to: 0 of the 2 requested resources.
in the vote data when a server fails to acquire the locks. This generic message makes it impossible at the time of the error to know which of the two locks could not be acquired. Knowing which lock was already acquired is useful for better tracking as in my case contention on the first lock is more expected, while contention on the second lock should be rare and thus a useful metric to alert on.I believe that this change could be implemented with a small tweak to the
acquire
script, and a larger change to the_attemptOperationOnClient
functions error handling, but I didn't want to create a PR for this change if there was no appetite for it.The text was updated successfully, but these errors were encountered: