feat: support for updating a drivers log configuration at runtime

[luke-rogers]

What is the motivation/use case for changing the behaviour?

I want to update the log levels at runtime to capture additional information for specific users of my application. This is useful when trying to debug an issue affecting a specific user without having to enable logging for all users or requiring the specific user to restart their application.

Describe the solution you'd like

A method to update a log driver's config at runtime - currently config is readonly.

Describe alternatives you've considered

• Wrapping the logger and implementing my own filtering of the logs based on this dynamic log-level configuration
• Creating a composite log driver, which creates and filters logs to the underlying drivers accordingly.

Additional context

[NachoVazquez]

Hey @luke-rogers ! How are you doing? Thanks for creating this ticket!

This is a valid use case; however, it feels weird that you would interact with the individual drivers directly.

Usually, the drivers are abstracted away by the LumberjackService, so it makes more sense that you would modify the log level there.

That said, we have an idea in place for a long time now that might solve your problem.

https://github.com/ngworker/lumberjack/issues/116

The idea is that when you create a log, you can pass an array of identifiers, and only the drivers matching those identifiers will be logged.

Just so you know, this will not require you to inject the drivers and change their config individually; everything will happen from the Lumberjack service's API surface, as designed.

Let me know if that solution works for you, and I'll work on it. Otherwise, I'd like to continue discussing something that works for you.

[luke-rogers]

Seems like that would work.

To add a bit more context to where this issue came from... we have a hybrid app and want to be able to enable remote log capture for specific users to help debug issues. This would be a custom driver which will write logs to disk and then upload them to support when people are working offline.

We will need the ability to tweak the log level for this custom driver differently from the console level as Sentry is capturing console logs so don't want to lose those if we want to turn off the 'write logs to disk' driver.

Hope that makes sense.

[NachoVazquez]

I might not get the whole picture, but if you are dealing with a single driver for these custom operations, I can imagine a couple of things that could help. Of course, there is the pattern that I mentioned yesterday. With that one, you can specify the target driver in your logs.

Another approach is to have a dynamic configuration, but this would work slightly differently than what you describe.

Instead of modifying the configuration before logging in, you would configure your driver using the provided method or a module. But instead of passing a configuration object, you will pass a function that returns the configuration object. That way, the driver will evaluate the function every time before logging, and you can put your custom restriction there. Notice this has an extra cost, and if your logic is complex and involves IO, this can affect the performance of your application.

Both approaches can live together.

I prefer the first option because it reduces the chances of the application breaking due to a driver configuration error. (I can imagine the amount of issues created blaming the library if that happens)

[NachoVazquez]

If you think it is helpful, please provide a snippet of code showing how you intend to use the library to achieve what you want. That might get us close to cracking the solution.