More granular error codes
See original GitHub issueHello. Briefly - how would I detect situation where I cannot get lock because of all Redis instanes gone (eg. db connection error on all instances).
More details:
try {
lock = await redlock.lock("x", 1000);
} catch (err) {
// Db connection problem (what I want to log and response with appropriate error code/message)
// OR
// Alredy locked by other instance of my app and I want to ignore it (eg. I will respond with 202 code to signal that task already in progress)
}
Is there a way I can distinguish between type of errors, eg:
- Unable to acquire/extend lock because of db connection error.
- Unable to acquire lock because resource already locked.
- Unable to extend lock because it already expired.
Is it possible that you will introduce LockError.code property and expose (export) some LOCK_ERROR_CODE_… consts?
Regards, Wojtek
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
java - Granularity of Exceptions
The main difference between having many different exception classes, and having only a few, with more detailed information in the error text ...
Read more >more granular error codes (6.1) - Dakota
Details: ENH: More granular error codes returned from abort_handler, including Boost exception containing the error.
Read more >Azure AD authentication & authorization error codes
Error codes are subject to change at any time in order to provide more granular error messages that are intended to help the...
Read more >Exception handling: how granular would you go when it ...
The new version of code will be hard to debug. In IsValidMessage() you check all the conditions in one line. How will you...
Read more >REST API Error Handling Best Practices
Twilio does a great job aligning errors with HTTP status codes. Like Facebook, they provide a more granular error message but with a...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi Mike, I got your point -
await lock()
request (promise) should not be rejected in each case because it will destory flow. Emitting event also have no sense in “classic” application that use step-by-step (non event) flow.IMO. it makes sense to reject it in case if connection to each db will fail, are you ok with this (or this is already implemented behavior)?
pon., 1 paź 2018 o 07:38 Mike Marcacci notifications@github.com napisał(a):
– Wojciech Fiderek
Mobile: +48 516 661 428
The newest version has all the relevant information attached to an error. Accessing all of this information is still a bit complex, because we can sometime know that something has errored before all parallel requests have completed. See the tests for an example of how to inspect these:
https://github.com/mike-marcacci/node-redlock/blob/078c7270a48596db8a23b4884f88db1f1eb3c18b/src/single.test.ts#L14-L31