Every start prints about 65 lines of the dependency-injection library's own log, and a startup error twice #359

Closed
opened 2026-11-11 21:13:26 +01:00 by clawbot · 1 comment
Collaborator

Found in the hands-on acceptance test of next (092176d), #356.

Steps

  1. Start pixad, from ./bin/pixad --config config.yml or the Docker image, and stop it.
  2. Start it with an invalid setting, for example PIXA_SIGNING_KEY=short.

What happened

  • Every start writes about 65 lines like [Fx] PROVIDE *config.Config <= sneak.berlin/go/pixa/internal/config.New() to stderr. Every stop writes about 20 [Fx] HOOK OnStop ... lines. docker logs mixes them with pixa's JSON log lines.
  • A startup error is printed twice. Each copy is wrapped in the library's frames (failed to build *config.Config: received non-nil error from function ... could not build arguments for function ...). The one useful line is buried among them: config key "signing_key" (environment variable PIXA_SIGNING_KEY): value too short: must be at least 32 characters, got 5.

The lines come from fx, the dependency-injection library. internal/app/app.go builds the fx app without fx.WithLogger, so fx writes its own event log.

What should happen

  • pixa's output holds only pixa's own log lines (slog, as README Architecture says).
  • A startup error is printed once, as the one line that names the setting, and pixa exits with status 1 as now.

Trap: fx.NopLogger alone also hides the startup error, since fx reports it through that logger. pixa must then print the error itself, for example from app.Err().

Model: opus-5-5

Found in the hands-on acceptance test of `next` (`092176d`), https://git.eeqj.de/sneak/pixa/issues/356. ## Steps 1. Start `pixad`, from `./bin/pixad --config config.yml` or the Docker image, and stop it. 2. Start it with an invalid setting, for example `PIXA_SIGNING_KEY=short`. ## What happened - Every start writes about 65 lines like `[Fx] PROVIDE *config.Config <= sneak.berlin/go/pixa/internal/config.New()` to stderr. Every stop writes about 20 `[Fx] HOOK OnStop ...` lines. `docker logs` mixes them with pixa's JSON log lines. - A startup error is printed twice. Each copy is wrapped in the library's frames (`failed to build *config.Config: received non-nil error from function ... could not build arguments for function ...`). The one useful line is buried among them: `config key "signing_key" (environment variable PIXA_SIGNING_KEY): value too short: must be at least 32 characters, got 5`. The lines come from `fx`, the dependency-injection library. `internal/app/app.go` builds the `fx` app without `fx.WithLogger`, so `fx` writes its own event log. ## What should happen - pixa's output holds only pixa's own log lines (`slog`, as README Architecture says). - A startup error is printed once, as the one line that names the setting, and pixa exits with status 1 as now. Trap: `fx.NopLogger` alone also hides the startup error, since `fx` reports it through that logger. pixa must then print the error itself, for example from `app.Err()`. Model: opus-5-5
Author
Collaborator

PR: #366, branch issue-359-quiet-fx-log, base next.

pixad builds the fx app with fx.NopLogger and runs start, wait and stop itself. It prints a start or stop error once, through dig.RootCause, and exits 1 as before. Two commits: failing tests first, then the fix.

Model: opus-5-5

PR: https://git.eeqj.de/sneak/pixa/pulls/366, branch `issue-359-quiet-fx-log`, base `next`. pixad builds the `fx` app with `fx.NopLogger` and runs start, wait and stop itself. It prints a start or stop error once, through `dig.RootCause`, and exits 1 as before. Two commits: failing tests first, then the fix. Model: opus-5-5
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/pixa#359