Add an option to change default action error logging

[greenzelenetskyi]

I have a suggestion to add an option to configure or maybe override the action error logging logic, as the log messages after errors seem to be too verbose and unnecessary in some cases. For example, it may be unnecessary to log stack trace of a custom app error, which is a part of the app logic, and log it with the same severity level as other errors. So I suggest giving some more control over error logging by adding some error filtering function, which can be overridden, and adding an action error level flag (something like logLevel for common action logging), to use in logAndReportAction (https://github.com/actionhero/actionhero/blob/master/src/classes/actionProcessor.ts#L110), for instance.

[evantahler]

This is a cool idea!

Rather than thinking about which actions should log their stack traces, I wonder if it's contextual. You might be throwing errors in your Action which don't indicate an exception with the application, but something that the user is doing is incorrect, ie throw new Error('not logged in'). I agree that logging the stack trace in these cases isn't required.

However, in the same action, what if an error like throw new Error('cannot connect to user database') was thrown? I think you would want that logged and traced in full...

With that in mind, perhaps the thing to do here is not to modify the logging behavior per Action, but per Error. A few ideas:

• Actionhero could have an /allow-list/ of Errors that match a certain pattern that should not be traced in full. If the error.message matches /^user error:/ for example, throw new Error('user error: not logged in) wouldn't generate a full logged stack trace
• We would rely on a property of the error itself. For example: const error = new Error('user not logged in'); error.log = false could be a way to signal that we shouldn't log the full stack trace.

Any other ideas?

[witem]

Maybe simple add filtration function, in default it always returns true. But with possibility to overwrite it and set custom logic, as developers like(using regexp or custom error type).

As example move https://github.com/actionhero/actionhero/blob/master/src/classes/actionProcessor.ts#L133-L146 to function that every one can overwrite.

api.config.general.actionErrorLogFiltrationAndFormat = (error, logLevel) => {
/* some logic */

return { logLine, logLevel };
}

Or split to two function, one for filtration, second for formatting.

[evantahler]

oh! I like that @witem! It moves the choice about how to render the error to the user (you can use the string error.message, error codes), whichever! This seems like another serializer to configure in config then (see https://github.com/actionhero/actionhero/blob/master/src/config/errors.ts)

[greenzelenetskyi]

I've created a PR with the changes discussed here: #1570. Could you please look at it and tell me what you think @evantahler?

[evantahler]

Just for clarity, here's the type of error I think you are talking about @greenzelenetskyi

2020-08-19T18:54:31.774Z - error: [ action @ web ] to=127.0.0.1 action=user:conversations params={"action":"user:conversations","apiVersion":"1"} duration=2 error=Error: Please log in to continue stack=Error: Please log in to continue
    at Object.preProcessor (/Users/evan/workspace/actionhero/actionhero-chat/api/src/initializers/session.ts:44:13)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at ActionProcessor.preProcessAction (/Users/evan/workspace/actionhero/actionhero-chat/node_modules/actionhero/dist/classes/actionProcessor.js:135:17)
    at ActionProcessor.runAction (/Users/evan/workspace/actionhero/actionhero-chat/node_modules/actionhero/dist/classes/actionProcessor.js:301:13)
    at WebServer.processAction (/Users/evan/workspace/actionhero/actionhero-chat/node_modules/actionhero/dist/classes/server.js:131:22)

[evantahler]

(from the https://github.com/actionhero/actionhero-chat example project)