Context
LoggingEvent.event(name) is authoritative for the reserved event structured key. When a caller also supplies a per-event field("event", …), the field value is dropped so the event carries the event key exactly once. (Duplicate keys are unsafe: SLF4J's addKeyValue appends rather than replaces, so emitting both produces two KeyValuePairs with the same name, which JSON appenders serialise as invalid duplicate-key JSON. See #132.)
The drop is currently surfaced at DEBUG, throttled to once per logger. DEBUG means most production deployments never see it, even though a caller-supplied value was silently discarded.
To decide
- Is DEBUG the right level, or should a genuine value-drop be WARN (still throttled)?
- Should a colliding
field("event") instead be rejected at the call site (e.g. IllegalArgumentException, since event() owns the key) rather than silently dropped?
- Or is drop-with-a-hint the right contract, and the work is just to document it more prominently in the
event() / field() KDoc?
Why a spike
The trade-off is log noise (WARN on a static call-site mistake) versus silent data loss (a DEBUG line nobody reads). Worth a short investigation and a deliberate decision recorded in the KDoc/docs rather than leaving the current default unexamined.
Context
LoggingEvent.event(name)is authoritative for the reservedeventstructured key. When a caller also supplies a per-eventfield("event", …), the field value is dropped so the event carries theeventkey exactly once. (Duplicate keys are unsafe: SLF4J'saddKeyValueappends rather than replaces, so emitting both produces twoKeyValuePairs with the same name, which JSON appenders serialise as invalid duplicate-key JSON. See #132.)The drop is currently surfaced at DEBUG, throttled to once per logger. DEBUG means most production deployments never see it, even though a caller-supplied value was silently discarded.
To decide
field("event")instead be rejected at the call site (e.g.IllegalArgumentException, sinceevent()owns the key) rather than silently dropped?event()/field()KDoc?Why a spike
The trade-off is log noise (WARN on a static call-site mistake) versus silent data loss (a DEBUG line nobody reads). Worth a short investigation and a deliberate decision recorded in the KDoc/docs rather than leaving the current default unexamined.