Feat: Enable LOG_LEVEL and LOG_FORMAT for 'historic' console.log/warn/error logging

[mrramam]

The problem

The database connection is opened with { verbose: console.log }, unconditionally, so every SQL statement the server runs is printed. On a Pi with one family calendar that measured ~8,450 journal lines per 15-minute sync cycle. That is 32 MB per 12 hours, enough to roll a 1 GB journald cap in about two days.

It is also a disclosure. better-sqlite3's verbose hook receives the expanded statement with bound values inlined, so calendar event titles and locations land in the journal in the clear. Parameterized statements do not protect the log.

There was no way to turn it down. No LOG_LEVEL existed, and the hook writes through console.log without touching Fastify's logger, so a Fastify level could not have suppressed it either.

What this changes

LOG_LEVEL, using pino's own vocabulary since Fastify's logger is pino: trace, debug, info, warn, error, fatal, silent. Default is warn, not pino's info. HomeGlow runs unattended on a display whose kiosk polls continuously, and a log nobody reads daily is most useful holding things that describe a problem.

SQL tracing moves to debug. The verbose hook is attached only when the level would emit it, because passing the hook at all makes the driver expand every statement whether or not anything consumes the result.

The global console is routed through the logger. The server has ~386 console.log/warn/error calls written over a year, and at every one of them the author already chose a severity by picking the method. This honors those choices. Each method maps to the level of the same name, so LOG_LEVEL governs all of it with no call-site changes. Arguments are flattened with util.format first: pino drops trailing arguments when the message has no placeholders, so a bare logger.info(msg, obj) would silently lose obj. This is an adoption shim, not an architecture; migration to explicit logger calls can proceed file by file, or never.

LOG_FORMAT: pretty (default) or json. Pretty drops pid and hostname since journald already stamps them, and keeps one event per line. json is for anyone feeding a pipeline. Adds pino-pretty.

Calendar sync logs at real levels: chatter at debug, a per-source summary at info, a missing source at warn, failures at error. A sync that breaks is still visible at the default, where before it was buried under ten lines a second of SQL.

The preHandler that printed Incoming request: per request is removed. Fastify's logger already emits incoming and completed lines with request id, status and duration, and obeys the level; the hook was a second, poorer copy no level could switch off.

Worth knowing

• At the default, a healthy boot prints nothing. Server running on port, Calendar sync service started and Fastify's own Server listening are all info. That is consistent and deliberate; /api/stats is the health check. Promoting a banner line to warn would misstate its severity.
• A successful sync is silent at the default; only failures surface. LOG_LEVEL=info brings back the per-sync summary, and per-request logging with it.
• Patching console is global: dependencies' console output obeys the level too. A reader who sees console.error in this codebase should know it is not writing to stderr.
• An invalid LOG_LEVEL or LOG_FORMAT falls back and says so at warn, so a misspelling is distinguishable from a value that worked.
• Not addressed here: the raw-rows dumps on GET /api/settings still print secret values whenever the level is info. That is a separate fix (remove the values), not a level.

Testing

23 tests across logLevel, logFormat and consoleShim. The ones that matter: at debug the driver is shown to echo bound values (the positive control), and at every quieter level nothing is captured; and console.log('Raw settings:', rows) keeps rows through the shim, the case a naive rewrite would lose.

Measured on the built image, 30 requests each: default 1 line (dotenv's, pre-shim); info 78; debug 127 with 49 SQL statements. Running on my own instance since 2026-09-15; a full sync cycle and 60 requests produced one journal line.