You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow structure logging "name already written" errors caused by MDC to be logged as warnings #45217
As discussed in #45063, currently an MDC name that has already been used will throw an IllegalStateException and prevent that message from being logged at all. It would be better if we allowed the structured logging to continue without the offending element and issued a warning instead.
Reacted by Kaj Hejer, janmlam, Zernov-A, glyoder, Yves Bos and Kim Kern
We do use structured logging and found a workaround just by setting the property logging.structured.json.context.prefix. So the error.id coming from elastic (and all other current mdc entries) gets wrapped in a sub-element named by this prefix.
Also ran into this issue. Would be great to log this only as warning. Currently i cannot reproduce the error locally so it would be good to see the generated json log to pinpoint the problem.
Maybe the duplicate name could be suffixed with a number? So you can see both values.
Hi, I'm not sure if my concern should be a separate issue, though it's closely related:
ECS defines other fields under the service apart from those specified in ElasticCommonSchemaProperties (name, version, environment, node). I can't find a clean way to supply, for instance "ephemeral-id" in a way that outputs under the service key (because of the same "The name 'service' has already been written"). Please note this isn't MDC-specific: I can't do it via properties or my own customizer or anything.
Forgot to make my point explicit :) : just logging a warning and continuing is great vs failing outright, but a design that can merge different fields under existing keys would be terrific
The solution mentioned by @jnewald does not cover another case:
If a name is defined in MDC as well as in a SLF4J KeyValue the same exception occurs.
IMHO the mistake here is that this should be controlled by a separate config property as it is arguably not context (for example: logging.structured.json.key-value.prefix)
Worth being aware of a second symptom of this failure mode on 4.1.0: when the IllegalStateException is thrown, the partial JSON of the failed event is left in the thread-local AppendableByteArray buffer used by WritableJson.toByteArray(Charset), and is emitted as a prefix to the next event logged on that thread — so the following event becomes invalid JSON as well.
That part looks like a separate bug (4.0.x is unaffected), so I have filed it as #51154 rather than adding it here.
Activity
wolframhaussig commentedon Sep 25, 2025
I am currently running into this issue, because I am using the Elastic APM Java Agent, and it adds the
error.idto the MDC:https://www.elastic.co/docs/reference/apm/agents/java/logs#log-correlation-ids
pauldburton commentedon Nov 7, 2025
@wolframhaussig have you figured out any way around this? We are in the same boat.
wolframhaussig commentedon Nov 10, 2025
Unfortunately not. Currently, we do not use the structured logging in our production versions....
snicoll commentedon Dec 26, 2025
There is a similar ask with a different context to consider when looking at this, see #47645.
jnewald commentedon Feb 4, 2026
We do use structured logging and found a workaround just by setting the property
logging.structured.json.context.prefix. So theerror.idcoming from elastic (and all other current mdc entries) gets wrapped in a sub-element named by this prefix.Unfortunately this property is sparely documented but it works.
michbeck100 commentedon May 7, 2026
Also ran into this issue. Would be great to log this only as warning. Currently i cannot reproduce the error locally so it would be good to see the generated json log to pinpoint the problem.
Maybe the duplicate name could be suffixed with a number? So you can see both values.
dmarmugi commentedon Jun 15, 2026
Hi, I'm not sure if my concern should be a separate issue, though it's closely related:
ECS defines other fields under the
serviceapart from those specified inElasticCommonSchemaProperties(name, version, environment, node). I can't find a clean way to supply, for instance"ephemeral-id"in a way that outputs under theservicekey (because of the same "The name 'service' has already been written"). Please note this isn't MDC-specific: I can't do it via properties or my own customizer or anything.Forgot to make my point explicit :) : just logging a warning and continuing is great vs failing outright, but a design that can merge different fields under existing keys would be terrific
WalterPongratz commentedon Jun 17, 2026
The solution mentioned by @jnewald does not cover another case:
If a name is defined in MDC as well as in a SLF4J KeyValue the same exception occurs.
IMHO the mistake here is that this should be controlled by a separate config property as it is arguably not context (for example: logging.structured.json.key-value.prefix)
edwardsre commentedon Jul 29, 2026
Worth being aware of a second symptom of this failure mode on 4.1.0: when the
IllegalStateExceptionis thrown, the partial JSON of the failed event is left in the thread-localAppendableByteArraybuffer used byWritableJson.toByteArray(Charset), and is emitted as a prefix to the next event logged on that thread — so the following event becomes invalid JSON as well.That part looks like a separate bug (4.0.x is unaffected), so I have filed it as #51154 rather than adding it here.