Skip to content

Duplicate _meta field during serialization when params already contains _meta (conflicts with WithMeta injection) #647

@Diferjfj

Description

@Diferjfj

Summary

When serializing requests/notifications, the library injects _meta into params via WithMeta, while also flatten-serializing the original params. If params itself already contains an _meta field, the resulting serialized params object effectively contains two _meta keys.

This is problematic because JSON objects must not contain duplicate keys. In practice it can result in:

ambiguous/invalid wire representation,

silent key overriding (“last key wins” behavior),

or serialization errors depending on the serializer backend.

A robust fix is to merge metadata from both sources and ensure only one _meta is emitted by removing _meta from the flattened params before serialization.

Steps to Reproduce

Construct a request where:

extensions contains a Meta, and

params also includes an _meta field (e.g. progressToken).

Example (conceptual):

extensions Meta: { "traceId": "abc" }

params: { "_meta": { "progressToken": 1 }, "foo": 42 }

Serialize the request.

Actual Behavior

The serializer builds:

_meta from extensions (injected by WithMeta._meta)

and also flattens params which already contains _meta

So the resulting JSON effectively becomes:

{
"method": "...",
"params": {
"_meta": { "traceId": "abc" },
"_meta": { "progressToken": 1 },
"foo": 42
}
}

This produces duplicate keys in the same object, which is not valid JSON. Depending on the serializer/consumer, this may:

drop one _meta silently,

override one with the other unpredictably,

or cause decoding/validation failures downstream.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions