-
Notifications
You must be signed in to change notification settings - Fork 456
Description
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.