Better CLI console experience when encountering errors or other logs

[ryoarmanda]

Is your request related to a problem?

I feel that our CLI console experience can be made more user-friendly when encountering warns, errors, or other info logs. There are some little clutters from progress-bars and errors/warns that take up a good chunk of the screen, which can make debugging a bit challenging, or can confuse authors.

Describe the solution you'd like

There are some improvements that I can think of:

• Have a progress bar that can not be visually disturbed by incoming logs (like apt-get's progress bar)
• (Not sure about this) make displayed errors user-friendly, maybe limiting/hiding the stack trace from the console but still be able to be checked via log files?

Describe alternatives you've considered

Additional context

[ang-zeyu]

Agree with item 2 (not too familiar on item 1 yet). We could also create a standardised logger method of sorts to encourage proper thought on what error messages we should present in the cli, rather than separate logger.error/debug methods

e.g.

// second property goes into the debug log
logger.printCliError('Oops, unknown error / file not found / ...', err.stackTrace)

[tlylt]

Agree with item 2 (not too familiar on item 1 yet). We could also create a standardised logger method of sorts to encourage proper thought on what error messages we should present in the cli, rather than separate logger.error/debug methods

e.g.

// second property goes into the debug log
logger.printCliError('Oops, unknown error / file not found / ...', err.stackTrace)

I think the default Winston loggers that we use are somewhat enough for classifying the logs into different levels (and until a certain level the logs will appear in the console). Might need to tweak the existing configs slightly to make it work, and then we can document what levels will be printed out to console in our DG as a reference. Having just the printCliError seems to defeat the purpose of classifying the logs based on severity. If it is too confusing with the default levels, then I guess we can create a custom cli level that users can use to logger.cliError (just as an example). Or we can also explore using the cli level that apparently exists:

I should say that working with Winston is such a pain that I think the difficulty is at least moderate .-.

[ang-zeyu]

Having just the printCliError seems to defeat the purpose of classifying the logs based on severity.

The issue isn't so much with severity, which I agree winston already handles well:

logger.printCliError('Oops, unknown error / file not found / ...', err.stackTrace) // e.g. this might just be implemented as a double-call to logger.error (cli) then logger.debug (log file)

err here is referring to error objects (propagated from try catch or elsewhere), which we log even for non-debug level messages.

purpose is for ⬇️

encourage proper thought on what error messages we should present in the cli

[tlylt]

encourage proper thought on what error messages we should present in the cli

Agree with this, we certainly can organize the logs better. Currently, we use a number of methods to log errors:

• logger.error(err.message); passing in the error message
• logger.error(error) passing in the error object
• logger.error('${name}' layout does not exist); passing in a custom message

I think if I am not wrong some will output stacktrace some won't.

same for logger.warn

err here is referring to error objects (propagated from try catch or elsewhere), which we log even for non-debug level messages.

May I just verify:

We want to skip logging stack trace to the console, but

• still logs to console any error messages provided by us
• still stores the error messages + stack trace in the log file?

[ang-zeyu]

We want to skip logging stack trace to the console, but

• still logs to console any error messages provided by us
• still stores the error messages + stack trace in the log file?

yup

We want to skip logging stack trace to the console, but

for this part specifically, maybe not universally.

It generally would not make much sense to present a stack trace, but there are times it is useful (file not found errors and such) (particularly where we don't have great error handling too).

We could work this out in parallel with #1863