OTP Logger: Per‑module filter not updating after handler reload

OTP Logger per‑module filtering

Since OTP 21, Logger supports custom filter modules that can be attached per handler. The handler’s filter is set to the module’s return value for each log message, allowing fine‑grained suppression of noise.

Dynamic update concern

When a filter module is edited and recompiled, the usual approach is to call logger:reload_handler/2 to apply the changes. However, the OTP documentation does not clarify whether the reload picks up the new module code or if the handler still references the old bytecode until a full node restart.

Additionally, the coexistence of the legacy error_logger can produce duplicate messages if both systems are active, further complicating noise reduction.

Given these uncertainties, we need to know how to reliably update filter logic at runtime and avoid silent loss of critical alerts.

• When a custom filter module is recompiled, does logger:reload_handler/2 load the new code, or must the node be restarted?
• Is there a documented mechanism to hot‑reload filter modules without handler removal?
• What best practice ensures that per‑module filters remain effective while minimizing duplicate logs from error_logger?