Open CMCDragonkai opened 2 years ago
Default verbosity should show us at least 2 things:
data
and othersIt is essential that the metadata should be mostly optional. That is, we should endeavour to describe what the error is in the message with all the relevant properties embedded in the message.
The exact output can be something like:
<ErrorName>: <Description> - <Message>
prop: value
Ideally in most cases the prop: value
is not shown at all. Such as in the case of ErrorPolykeyRemote
, the message property should have all the relevant information stored in it. That way we could see something like:
ErrorPolykeyRemote: Remote error from RPC call - Pinging remote node `vasrqbpb1u51khi7ibg5j63ai3odomhj6js348k1ra5jffjuvrhsg@127.0.0.1:37595` with `nodesPing` failed
I think having the error class name up front might be bad UX for non-technical users. Most examples I see in the wild has the "code" later.
Remote error from RPC call - Pinging remote node vasrqbpb1u51khi7ibg5j63ai3odomhj6js348k1ra5jffjuvrhsg@127.0.0.1:37595 with `nodesPing` failed - #ErrorPolykeyRemote
// or
Remote error from RPC call: Pinging remote node vasrqbpb1u51khi7ibg5j63ai3odomhj6js348k1ra5jffjuvrhsg@127.0.0.1:37595 with `nodesPing` failed - #ErrorPolykeyRemote
Note sure yet. It's probably a good idea to have a short version of the node id too.
Commands will need to interpret why it is failing, and provide a custom message (think of this like "localisation") for that specific problem, and then a default message in case it's not one of the expected errors. I believe we deal with this just by creating another exception, and then rethrow it with exception override pattern.
Structured logging is available now, we can make use of it to achieve this. As well as potentially incorporating https://github.com/davidmarkclements/fast-redact for redacting structured information.
JSON structured logging is now being integrated with MatrixAI/Polykey#421.
Atm, still no verbosity control is applied to exception/error reporting.
At the same time, the reporting of errors is different from the logger. The logger isn't used for reporting exception error information to STDERR.
We may look into standardising the reporting of both errors and logs, so that reporting of
root exceptions goes through the same logger system. Right now non-root exceptions are being reported with logger.error
, however it doesn't do any special handling.
At the same time, I want to investigate tracing https://github.com/MatrixAI/js-logger/issues/15, if tracing wraps around logger, then our child loggers are replaced with "child spans". These spans then may add additional context around exceptions that get reported.
So while exceptions themselves have a low-level stack trace regarding the function call graph, our tracing spans provides a more "global" overview from object contexts to distributed system RPC.
So any unification of error logging and structured logging and human readable logging should be designed together.
Moving to Polykey-CLI.
The Logger
supports dynamic setFilter
.
Add a new command line option to the PK CLI so that one can provide a filter expression (regexp) that will be set to the root logger to control it.
Note that this can affect 2 things:
pk bootstrap
and pk agent start
(but you have to separate filters for the agent, vs the main program)If you want to dynamically control the filter on the agent program - that can be done, but it requires a client service handler that has access to pkAgent.logger
and set the filter there. Remember that's stateful. You could also dynamically set the level too.
Solving the verbosity problem also helps obviate #107. See the comment there: https://github.com/MatrixAI/Polykey-CLI/issues/107#issuecomment-2304453813.
I'm also kind of thinking inverted messages is not a good idea because it won't match with when the verbosity increases.
There are primarily 3 kinds of verbosity here:
- Verbosity of Exception/Error Reporting that goes to STDERR
- Verbosity of Log Messages that goes to STDERR
- Verbosity of Status Updates that also goes to STDERR
Previously I understood 2. and 3. to be the same thing... but they are slightly different. the PK CLI outside of the
agent start
operation doesn't tend to uselogger
at all. But actually if it did use logger, its messages would be classified under 3.Verbosity should not affect STDOUT output/result of a command. That should also be based on the output formatter.
165
Specification
The
--format=human
or--format=json
now controls the STDERR reporting of exceptions. See: MatrixAI/Polykey#323.However the verbosity of the report should be controlled with our
--verbosity
flag.For
--format=json
because we expect this to be processed by machines, we can say that--verbose
doesn't affect it, and instead all information is produced.However for
--format=human
we can progressively show more information.Right now without a verbosity flag, our logging level is set to show warnings and up. With the
-v
we get info logs, and-vv
we get debug logs. This means we can think of having 3 levels of error reporting.The default level without a
-v
should be assumed to be used by an end-user of the CLI program, who will probably never look at the source code of PK. Which means, any error we report should only really have the error description and error message. The error name can be useful, if they want to report the error to the dev who can identify the exception.With
-v
, extra information about the error should be shown, this should probably mean all the properties except thestack
property and this applies recursively to the cause chain.Finally with
-vv
we should show the stack property as well.This should apply to exceptions reported on the
src/bin/polykey.ts
andsrc/bin/polykey-agent.ts
. In the case ofPolykeyAgent
, this depends onpk agent start -vv
, verbosity flags passed frompk agent start
subcommand.Additional context
Tasks
outputFormatter
. Use the verbosity level. It should be a number.pk agent start
-v
means and-vv
means.