Loading
docs(specs): harden S03 logging spec against LabKit v2 behavior
What
Hardens the S03 logging spec by validating every claim for logging package + config conversion + handler chain built on labkit/v2 v2.13.0 and correcting the spec where it proved wrong or underspecified.
Why
The prior text rested on LabKit behavior that does not exist in v2.13.0 (a
ContextHandler/logFields auto-stamping mechanism) and on a config-defaulting
flow that labkit/v2/config's Loader.Load cannot support (protovalidate runs
atomically inside the load, so a pre-validation defaulter is impossible).
Key corrections
- Config:
level/formatmove from proto enums (which fail buf-lintENUM_VALUE_PREFIXand forceLEVEL_/FORMAT_YAML) tostring+in:fields with Go-side defaults, matching the existingdatabase.sslmodeprecedent.success_fractionkeepsEXPLICITpresence so unset (default1.0) is distinguishable from explicit0.0. - Handler chain: no LabKit
ContextHandlerexists. The service owns the chain (sampler → context-field → base), mapsLogConfigintoapp.Config.Log, and wrapsa.Logger().Handler()soversion/commit/build-datesurvive. The enriched logger is installed as the request-context logger (log.WithLogger). - Sampler reads
status(fields.HTTPStatusCode), notstatus_code(a deprecated alias infields.Deprecated). - Wide events: success/error field renamed
status→outcometo avoid the int/string type collision with the canonical HTTPstatus. Clarified that wide events are INFO and subject to thelog.levelthreshold. - Dropped the wide-event CI validator (former AC6) and all validator references: the typed-emitter pattern, the catalog, and code review are the enforcement. A bespoke source-scanning tool is disproportionate for the logging phase and has no tooling precedent in this repo.
Edited by Suleimi Ahmed