AdguardTeam / AdguardTeam/AdGuardHome

AGH: {{log.enabled: false}} leaves the legacy logger enabled

Abierto
#8,565 4 comentarios 0 reacciones 1 asignado Reclamado por @Chinaski1 Ver en GitHub
Priority: P4 Status: In Progress
Lenguaje dominante
TypeScript
Estrellas
36.9k
Forks
2.5k
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

### Prerequisites

- [x] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a) and found no answer
- [x] I have searched other issues and found no duplicates
- [x] I want to report a bug and not ask a question or ask for help
- [x] I have set up AdGuard Home correctly and configured clients to use it

I found this while investigating the macOS service-log behavior in #8564. I
use and really like AdGuard Home on my Mac, so I followed the logging path a
little further and noticed this separate, platform-independent regression.

I am filing it separately because it is a small bug with a small fix, and it
does not belong in the larger macOS logging change.

### Plain English

AdGuard Home is moving from an older logger to a newer one. Setting
`log.enabled: false` correctly silences the newer logger, but the older logger
can remain switched on. The fix makes the same off switch control both.

### Platform (OS and CPU architecture)

All platforms. Reproduced from a source checkout on macOS ARM64.

### Installation

Source checkout of current `master`.

### Setup

Focused logger regression test; the defect is platform-independent.

### AdGuard Home version

Current `master` at `090f75d79fcad19a7447d158fc926a304b0dff57`.

### Action

Load logging settings with:

```yaml
log:
enabled: false
```

Then construct the configured logger. The focused unchanged-code regression
sets the transitional legacy logger to `INFO`, calls `newSlogLogger` with
`Enabled: false`, and checks its resulting level.

### Expected result

Both the structured logger and the transitional
`github.com/AdguardTeam/golibs/log` logger are disabled, matching the feature
introduced for #7079. The legacy logger level should be `OFF`.

### Actual result

`newSlogLogger` returns the discard structured logger before reaching the
existing `log.SetLevel(log.OFF)` branch. The structured logger is disabled,
but the legacy logger remains at its previous level and may continue emitting.

The unchanged-code regression produced:

```text
expected legacy log level: OFF
actual legacy log level: INFO
```

### Additional information and/or screenshots

I have a two-line fix ready that moves `log.SetLevel(log.OFF)` into the disabled
early-return path and removes the unreachable duplicate condition. It is
isolated on a one-commit branch with a changelog entry and regression test.

Proof after the fix:

```sh
go test -race ./internal/home -run '^TestNewSlogLoggerDisabled$' -count=20
```

The focused test passed 20 consecutive runs, and the full `make go-check`
suite passed. This change is intentionally separate from the proposed macOS
service-logging enhancement.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.