sneak/netwatch
1
0 Fork 0
Code Issues 5 Pull Requests 1 Actions 8 Packages Projects Releases Wiki Activity

The backend's log starts with 43 lines of framework internals, and a bad setting's reason is buried in them #209

New Issue
Closed
opened 2026-11-11 21:16:30 +01:00 by clawbot · 1 comment
clawbot commented 2026-11-11 21:16:30 +01:00
Collaborator
Copy link
Copy source

netwatch-server logs each step of its startup framework (fx) at INFO: 43 lines on every start of the image, each with a source path and some with a stack trace. When a setting is invalid, the reason appears only inside three ERROR lines of about 700 characters each. These lines are mostly framework text, such as "could not build arguments for function". The container's last log line is entrypoint: netwatch-server exited 1, nginx exited 0, which does not say why.

Found by the acceptance test on #204.

Steps: make docker, then docker run --rm -e REPORTS_PER_MINUTE=0 netwatch. The same holds for REPORTS_PER_MINUTE=0 ./netwatch-server after make build.

What happens: the reason, REPORTS_PER_MINUTE "0": must be a positive whole number, is in line 29 of 271, in the middle of a framework message.

What should happen:

  • A normal start logs no framework lines at INFO. They appear only with DEBUG set.
  • An invalid setting stops the server with one short line naming the variable and the reason. That line is the last one the backend logs.

Definition of done

  • A normal start of the image logs no framework lines unless DEBUG is set.
  • With REPORTS_PER_MINUTE=0, the backend's last log line is one short line naming REPORTS_PER_MINUTE and why the value is refused.
  • README.md, Logging, still matches what the backend logs.

Model: opus-5-5

`netwatch-server` logs each step of its startup framework (`fx`) at INFO: 43 lines on every start of the image, each with a source path and some with a stack trace. When a setting is invalid, the reason appears only inside three ERROR lines of about 700 characters each. These lines are mostly framework text, such as "could not build arguments for function". The container's last log line is `entrypoint: netwatch-server exited 1, nginx exited 0`, which does not say why. Found by the acceptance test on https://git.eeqj.de/sneak/netwatch/issues/204. **Steps**: `make docker`, then `docker run --rm -e REPORTS_PER_MINUTE=0 netwatch`. The same holds for `REPORTS_PER_MINUTE=0 ./netwatch-server` after `make build`. **What happens**: the reason, `REPORTS_PER_MINUTE "0": must be a positive whole number`, is in line 29 of 271, in the middle of a framework message. **What should happen**: - A normal start logs no framework lines at INFO. They appear only with `DEBUG` set. - An invalid setting stops the server with one short line naming the variable and the reason. That line is the last one the backend logs. ## Definition of done - [ ] A normal start of the image logs no framework lines unless `DEBUG` is set. - [ ] With `REPORTS_PER_MINUTE=0`, the backend's last log line is one short line naming `REPORTS_PER_MINUTE` and why the value is refused. - [ ] `README.md`, Logging, still matches what the backend logs. Model: opus-5-5
clawbot commented 2026-11-11 21:33:51 +01:00
Author
Collaborator
Copy link
Copy source

PR: #219, branch issue-209-quiet-fx-startup-log.

fx's lines now log at debug level, so a normal start shows none of them. When a setting is refused, the backend's last line is one cannot start error naming the setting and the reason. README Logging describes both.

Disclosure: with DEBUG set, fx's lines from before the settings are read are still dropped, because debug level turns on only when the settings are read.

Model: opus-5-5

PR: https://git.eeqj.de/sneak/netwatch/pulls/219, branch `issue-209-quiet-fx-startup-log`. `fx`'s lines now log at debug level, so a normal start shows none of them. When a setting is refused, the backend's last line is one `cannot start` error naming the setting and the reason. README Logging describes both. Disclosure: with `DEBUG` set, `fx`'s lines from before the settings are read are still dropped, because debug level turns on only when the settings are read. Model: opus-5-5
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
critical
Extremely important: data loss, a security hole, production down, or basic use impossible
 merge-ready
needs-checks
needs-rebase
needs-review
needs-rework
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
clawbot sneak (Jeffrey Paul)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/netwatch#209