Skip to content

Allow structure logging "name already written" errors caused by MDC to be logged as warnings #45217

Open

Description

@philwebb

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.

Activity

  1. added this to the 3.x milestone on Apr 17, 2025
  2. wolframhaussig commented on Sep 25, 2025

    @wolframhaussig

    I am currently running into this issue, because I am using the Elastic APM Java Agent, and it adds the error.id to the MDC:
    https://www.elastic.co/docs/reference/apm/agents/java/logs#log-correlation-ids

  3. pauldburton commented on Nov 7, 2025

    @pauldburton

    I am currently running into this issue, because I am using the Elastic APM Java Agent, and it adds the error.id to the MDC: https://www.elastic.co/docs/reference/apm/agents/java/logs#log-correlation-ids

    @wolframhaussig have you figured out any way around this? We are in the same boat.

  4. wolframhaussig commented on Nov 10, 2025

    @wolframhaussig

    I am currently running into this issue, because I am using the Elastic APM Java Agent, and it adds the error.id to the MDC: https://www.elastic.co/docs/reference/apm/agents/java/logs#log-correlation-ids

    @wolframhaussig have you figured out any way around this? We are in the same boat.

    Unfortunately not. Currently, we do not use the structured logging in our production versions....

  5. modified the milestones: 3.x, 4.x on Nov 11, 2025
  6. snicoll commented on Dec 26, 2025

    @snicoll
    Member

    There is a similar ask with a different context to consider when looking at this, see #47645.

  7. jnewald commented on Feb 4, 2026

    @jnewald

    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.

    Unfortunately this property is sparely documented but it works.

  8. michbeck100 commented on May 7, 2026

    @michbeck100

    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.

  9. dmarmugi commented on Jun 15, 2026

    @dmarmugi

    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

  10. WalterPongratz commented on Jun 17, 2026

    @WalterPongratz

    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)

  11. edwardsre commented on Jul 29, 2026

    @edwardsre
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions