4837 introduced a significant change to the configuration: logger.level parameter is now not just a level, but actually a set of filtering directives. This has a few problems:
Using level parameter is inappropriate for this configuration. Level is level, not an advanced filter.
Not documented anywhere neither that this change was made nor how to use these filters. I found it by accident (thanks to tests) in JS SDK when expected that { "logger": { "level": "TR" } } payload for POST /configuration will fail.
It must be reflected on Torii reference (config reference is still wip)
Additionally, it just feels frustrating that after emphasizing many times in the Config RFC #3795 that configuration must be taken extra care of in terms of documentation, proper design choices, and breaking changes.
Proposal
Revert logger.level (LOG_LEVEL) to be strictly log level as before
Introduce logger.filter (LOG_FILTER) in addition to it. Document it's usage well
They can work both, without conflicts, since they could work on different layers of tracing
Context
4837 introduced a significant change to the configuration:
logger.levelparameter is now not just a level, but actually a set of filtering directives. This has a few problems:{ "logger": { "level": "TR" } }payload forPOST /configurationwill fail.Additionally, it just feels frustrating that after emphasizing many times in the Config RFC #3795 that configuration must be taken extra care of in terms of documentation, proper design choices, and breaking changes.
Proposal
logger.level(LOG_LEVEL) to be strictly log level as beforelogger.filter(LOG_FILTER) in addition to it. Document it's usage well