Scope Response.Update AdditionalProperties by MessageID

[PratikDhanave (PratikDhanave)]

Response.Update copied update.AdditionalProperties into both the target message's AdditionalProperties and the response-level AdditionalProperties. So message-scoped provider metadata (an update carrying a MessageID) leaked up to the response, and response-scoped metadata (an update with no MessageID) leaked onto whichever message was current — duplicated and mis-attributed versus .NET.

Response.Update is a direct port of M.E.AI ChatResponseExtensions.ProcessUpdate, which scopes these either/or:

AdditionalProperties are scoped to the message if the update has a MessageId, otherwise theyre scoped to the response.

Change

• Copy to the message only when update.MessageID != "", and to the response only when it is empty.

Test

• TestResponse_Update_AdditionalPropertiesScopedByMessageID: with a MessageID the props land on the message and the response stays empty; without one they land on the response and the message stays empty. Both halves fail before the change (props on both), pass after. The existing TestResponse_Update_AdditionalProperties (always uses a MessageID, asserts the message side) still passes.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Empty-message-ID round trips can misplace message-scoped properties on the response.

Review effort: Lite
Findings: None

What changed in this PR

Updates Response.Update to scope AdditionalProperties by MessageID, with regression tests for message- and response-level metadata.

Changes:

• Applies metadata to only the appropriate scope.
• Adds coverage for both scoping cases.

File	Description
agent/​response.go	Implements MessageID-based metadata scoping.
agent/​response_test.go	Tests message- and response-level property behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Scope: user-visible behavior (bug fix; no exported API surface change)

Changed Go contract: agent.Response.Update(update *ResponseUpdate) — internal scoping logic for copying update.AdditionalProperties into msg.AdditionalProperties vs. resp.AdditionalProperties. No exported types, methods, fields, or signatures were added/removed/changed.

Upstream evidence reviewed: Microsoft.Extensions.AI.Abstractions/ChatCompletion/ChatResponseExtensions.cs (private ProcessUpdate(ChatResponseUpdate update, ChatResponse response), lines ~592-616) in dotnet/extensions, which Microsoft.Agents.AI.ChatClient.ChatClientAgent builds on for ChatResponse construction. The upstream comment states verbatim: "AdditionalProperties are scoped to the message if the update has a MessageId, otherwise they're scoped to the response," implemented as an either/or if (update.MessageId is { Length: > 0 }) { message... } else { response... } — never both.

Result: aligned. The Go change makes Response.Update an exact behavioral port of the upstream either/or scoping (message-only when MessageID != "", response-only when empty), fixing a prior divergence where Go copied to both targets unconditionally. This is a pure bugfix restoring parity with .NET; no public Go API was added, removed, or changed, and the fix does not require any corresponding gate/option since upstream has none either — this is unconditional behavior in both implementations. Test coverage (TestResponse_Update_AdditionalPropertiesScopedByMessageID) matches the upstream either/or semantics.

No public-api-change label needed (no exported API changed). Recommending parity-approved.

Generated by Go API Consistency Review Agent · copilot · auto · 27.5 AIC · ⌖ 13.3 AIC · ⊞ 9.2K · ◷