31 releases 31 tags

RSS feed

• v1.10.0 e65723eb5a

  Compare

  v1.10.0 — readable boot output Stable

  joeyr released this 2026-08-02 22:33:22 -05:00 | 3 commits to main since this release

  These logs are read in Portainer, whose JSON log viewer renders exactly five
  keys — time, level, caller, message, stack_trace — and demotes every
  other key to a trailing key=value pair at the far end of the line. aufhocker
  was emitting its timestamp under a name that viewer does not know, and burying
  its startup configuration in a wall of JSON.

  First of three releases fixing that; see docs/LOGGING_PLAN.md.

  Changed

  • The timestamp is time, not timestamp. Winston writes its timestamp to
    info.timestamp, which is not one of the five, so every line arrived with no
    timestamp column at all and the clock trailing the fields. Renamed once in
    the logger's format, immediately after format.timestamp() — no call site
    changed.
  • service=aufhocker no longer appears on every line. defaultMeta put it
    on all of them, as one more demoted key=value pair; the container name
    already says which service these came from.
  • The startup configuration is six lines rather than one.
    Config.getSummary() returned a deeply nested object
    (storage.databaseTarget.host), and an unrecognised key holding an object is
    flattened to JSON inside its trailing pair — so the first thing you saw in
    the logs was a single very long line of JSON. It is now getSummaryLines():
    one line per area (config/runtime, config/discord, config/claude,
    config/storage, config/limits, config/admin), flat scalar fields only,
    each tagged with a caller so the group reads as a section instead of six
    unrelated boot messages. Secrets stay masked exactly as before — booleans for
    keys, and the database as host:port/database, never the DSN, which carries
    the password.
  • The production stdout transport no longer re-applies format.timestamp(). A
    transport format runs after the logger's, so it would have written a fresh
    timestamp key and undone the rename on the one transport Portainer reads.

  Added

  • tz in the config/runtime line. The deploy sets TZ=America/Chicago,
    and this is the only way to tell from the outside which clock every time
    field is written against.
  • databaseLabel() alongside describeDatabaseUrl() in the config module —
    the same parse, rendered as one host:port/database field.

  Deployment

  TZ=America/Chicago is a stack edit (aufhocker.yaml), not part of the
  image: update the stack in Portainer, or the new time field keeps reading
  UTC. Nothing else in the bot schedules off local time — the d2emu poll fires on
  the :00/:30 minute marks and America/Chicago is a whole-hour offset from
  UTC, so its schedule is unchanged to the millisecond.

  ---

  Minor rather than patch for the changed log output. No schema, command, or
  config-input changes. caller tags on every line, real stack traces, and a
  boot preflight block follow in two further releases.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads