Closed dtfiedler closed 11 months ago
Neat approach, though it may come with some tradeoffs. I like how it consolidates handling of sending the error response and makes handler code a bit more succinct and happy path focused. I think what you lose, however, is the ability for your child loggers in the handler, which may have helpful debugging context, to connect the error they CAN see in the handler code with the error they CAN'T see in the error handler. TraceIDs will alleviate that at debugging time when you've already found your needles in the haystack, but might be more difficult to find the needles you're looking for altogether.
Neat approach, though it may come with some tradeoffs. I like how it consolidates handling of sending the error response and makes handler code a bit more succinct and happy path focused. I think what you lose, however, is the ability for your child loggers in the handler, which may have helpful debugging context, to connect the error they CAN see in the handler code with the error they CAN'T see in the error handler. TraceIDs will alleviate that at debugging time when you've already found your needles in the haystack, but might be more difficult to find the needles you're looking for altogether.
yeah - you lose that a bit - that’s where the type of errors and the messages you include in them would become more important. you can also still use try/catch in your handlers for logging purposes, then just propagate the error up the the middleware to determine status code. i’m not sure this approach would be very useful in upload-service, where our error paths are complex and debugging logs are critical for understanding where errors originate.
…n their types and returns proper status codes
This type of middleware is particularly useful for this problem. We have various instances in which warp throws errors when failing to evaluate a contract state, and we want to parse those properly and return the correct status code when they occur. Right now we over thrown 503 errors, which suggest to clients that the app failed to process, when it's more likely they are requesting contracts that have not been mined yet or do not adhere to specs defined by warp. By using the middleware, we catch any errors thrown by our handlers, and properly set status codes based on the type of error.
It's intentionally added after the logger middleware so it has access to the logger (with trace id, request path, etc.) when logging out the error message before returning.
TODO:
TX_NOT_FOUND
errors in warp - occurs for new contracts deployed that have not been mined OR one that has a source contract that does not existTesting
Missing source code tx
Before
After
Non-existent contract
Before
After