Skip to content

Add _meta to UserMessage#168

Merged
connor4312 merged 2 commits into
mainfrom
colbylwilliams/message-meta-field
May 28, 2026
Merged

Add _meta to UserMessage#168
connor4312 merged 2 commits into
mainfrom
colbylwilliams/message-meta-field

Conversation

@colbylwilliams
Copy link
Copy Markdown
Member

Adds an optional _meta?: Record<string, unknown> field to UserMessage so user messages can carry provider-specific metadata, mirroring the MCP _meta convention already used on MessageAttachmentBase, ToolDefinition, ToolCallBase, UsageInfo, and SessionState.

Changes

  • types/channels-session/state.ts: add UserMessage._meta with JSDoc describing the MCP-aligned semantics.
  • Generated clients: regenerated via npm run generate. _meta lands as the idiomatic optional map type in each client:
    • Go: Meta map[string]json.RawMessage \json:"_meta,omitempty"``
    • Kotlin: @SerialName("_meta") val meta: Map<String, JsonElement>? = null
    • Rust: #[serde(rename = "_meta", default, skip_serializing_if = "Option::is_none")] pub meta: Option<JsonObject>
    • Swift: public var meta: [String: AnyCodable]? with CodingKey meta = "_meta" (and init gains a trailing meta: parameter defaulting to nil)
  • Schemas: schema/*.schema.json regenerated; UserMessage picks up an optional _meta object.
  • Docs: docs/guide/state-model.md shows _meta in the UserMessage snippet and adds a paragraph distinguishing it from the existing attachment-level _meta blob.
  • CHANGELOGs: root spec changelog plus every client changelog (Go, Kotlin, Rust, Swift, TypeScript) gain an Added bullet under ## [Unreleased] per the AGENTS.md "types/** ripples to every client" rule.

Validation

  • npm run generate — clean
  • npm run typecheck — clean
  • npm run lint — clean
  • npm run verify:release-metadata — passes
  • npm run verify:changelog — passes
  • npx tsx --test types/*.test.ts types/version/*.test.ts224/224 passing (the npm run test wrapper otherwise trips the pre-existing c8/yargs incompatibility on Node 26 in this dev env, unrelated to this change)

Compatibility

Purely additive. Existing producers and consumers that ignore _meta continue to round-trip messages unchanged, so no protocol version bump is required.

Coordination with #155

#155 renames UserMessageMessage and adds a MessageKind discriminant. This PR was deliberately scoped to a single additive field on UserMessage so the new _meta field will carry forward cleanly into Message._meta when #155 lands (or rebases on top of this).

(Written by Copilot)

colbylwilliams and others added 2 commits May 28, 2026 15:58
Adds an optional `_meta?: Record<string, unknown>` field to `UserMessage`
so user messages can carry provider-specific metadata, mirroring the MCP
`_meta` convention already used on `MessageAttachmentBase`,
`ToolDefinition`, `ToolCallBase`, `UsageInfo`, and `SessionState`.

Regenerates the JSON Schema and Go/Kotlin/Rust/Swift/TypeScript clients
(`_meta` lands as the idiomatic optional map type in each), updates
`docs/guide/state-model.md` to document the new field, and bumps the
`Unreleased` section in the spec changelog plus every client CHANGELOG.

This is purely additive — existing producers and consumers that ignore
`_meta` continue to round-trip messages unchanged. It is also designed
to merge cleanly into #155, which renames `UserMessage` → `Message` and
will carry the new field forward as `Message._meta`.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rust struct literals must exhaustively list every field, so the existing
hand-written test fixtures in `crates/ahp/src/reducers.rs` failed to
compile after `UserMessage` gained the optional `meta` field. Kotlin,
Swift, Go, and TypeScript construction sites pick up the new optional
field via their language-default values (`null`, `nil`, zero, omitted)
and need no changes.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds an optional _meta field to UserMessage so user messages can carry provider-specific metadata, mirroring the existing MCP _meta convention used elsewhere in the protocol (attachments, tool definitions, tool calls, usage info, session state). The change is purely additive and regenerates all client bindings and schemas.

Changes:

  • Add _meta?: Record<string, unknown> to UserMessage in types/channels-session/state.ts with JSDoc.
  • Regenerate JSON schemas and all client bindings (Go, Kotlin, Rust, Swift) plus update Rust reducer test fixtures.
  • Update docs and root + per-client CHANGELOGs under [Unreleased].
Show a summary per file
File Description
types/channels-session/state.ts Source-of-truth: adds _meta to UserMessage.
schema/{state,notifications,errors,commands,actions}.schema.json Regenerated schemas pick up optional _meta on UserMessage.
docs/guide/state-model.md Documents _meta on UserMessage and contrasts with attachment _meta.
clients/typescript/CHANGELOG.md Adds [Unreleased] entry.
clients/swift/AgentHostProtocol/.../State.generated.swift Adds meta property, CodingKey, and init parameter.
clients/swift/CHANGELOG.md Adds [Unreleased] entry.
clients/rust/crates/ahp-types/src/state.rs Adds meta: Option<JsonObject> with #[serde(rename = "_meta", …)].
clients/rust/crates/ahp/src/reducers.rs Updates UserMessage literals in tests with meta: None.
clients/rust/CHANGELOG.md Adds [Unreleased] entry.
clients/kotlin/.../State.generated.kt Adds meta field with @SerialName("_meta").
clients/kotlin/CHANGELOG.md Adds [Unreleased] entry.
clients/go/ahptypes/state.generated.go Adds Meta map[string]json.RawMessage field.
clients/go/CHANGELOG.md Adds [Unreleased] entry.
CHANGELOG.md Adds root spec [Unreleased] entry.

Copilot's findings

  • Files reviewed: 16/18 changed files
  • Comments generated: 0

@connor4312 connor4312 merged commit 42197d6 into main May 28, 2026
9 checks passed
@connor4312 connor4312 deleted the colbylwilliams/message-meta-field branch May 28, 2026 21:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants