fix(qe): fix error logging #16287

In case error logging is enabled in the client, a middleware captures errors and uses the event emitter to notify about them. This way, errors are captured in the same way accross the different engines, by capturing errors one level above in the call stack (at the client level) After this approach is validated, next commits will: - Filter the kind of errors that should be logged - Create the appropriate structure for the logging event being emitted - Add unit tests to check the behavior with the binary engine.

Our middleware is FIFO (a queue rather than an actual stack) so the first middleware would call on other middlewares defined by the user before hitting the actual request. As we don't want to observe on users's middleware errors, I moved the logic from a middleware to the point where the request is being made. Also notice we don't want to block on user handling code upon request resolving, so the error handling code runs asynchronously. This has a side effect. If the execution of the program halts, before the promise is resolved in the next event loop tick, then the error won't be logged. This might not be an acceptable trade-off, and I might change it in a follow-up commit.

Error will flow up the stack and be captured by the RequestHandler

Co-authored-by: Daniel Starns <danielstarns@hotmail.com>

This change is about: 1. getting rid of lastErrorLog, lastRustError, lastPanic state and instead build all the error information when we parse a log line if that's pertinent 2. Let request errors flow up the stack instead to be emitted in the RequestHandler. 3. Only emit events explicitly during lifecycle management of the binary engine

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(qe): fix error logging #16287

fix(qe): fix error logging #16287

Commits on Nov 24, 2022