Preserve large-integer precision when decoding FunctionResultContent.Result

[PratikDhanave]

What

FunctionResultContent.UnmarshalJSON decoded the JSON Result into an any via json.Unmarshal. Go's encoding/json decodes JSON numbers into any as float64, so integers above 2^53 were silently corrupted on the round trip (9007199254740993 became 9007199254740992). Because MarshalJSON emits the exact int64, a Marshal followed by Unmarshal was not idempotent for large-integer tool results, which bites checkpoint save/restore and provider re-serialization.

This change adds a serializedFunctionResultContentForUnmarshal struct whose Result is a json.RawMessage, and decodes it in UnmarshalJSON with a number-preserving decoder (json.NewDecoder(...).UseNumber()). Numeric leaves become json.Number, so large integers stay exact. MarshalJSON is unchanged, mirroring the existing serialized...ForUnmarshal pattern already used in this file for tool-approval content.

Why (parity)

This matches .NET's JsonElement-based preservation of tool-result payloads, where numeric values are not eagerly narrowed to a lossy floating-point representation. It is distinct from #528, which fixed FunctionCallContent.Arguments (a string field); the result payload is an arbitrary any and needed a separate fix.

How it is tested

Added TestFunctionResultContentRoundtripPreservesResult in the canonical message/content_test.go. It marshals a FunctionResultContent, unmarshals it, and re-marshals, asserting the two JSON byte slices are byte-identical and that a large integer (9007199254740993) survives exactly. Small-int and string-result cases guard against regressions. The test fails before the change (round-tripped value is 9.007199254740992e+15) and passes after.

go build ./..., go vet ./message/..., and go test ./message/... all pass.

[Copilot]

Pull request overview

This PR fixes lossy decoding of FunctionResultContent.Result by switching UnmarshalJSON to decode the Result payload with a number-preserving JSON decoder (UseNumber), preventing large integers (> 2^53) from being silently corrupted and making internal marshal/unmarshal round-trips stable for tool results.

Changes:

• Add an unmarshal-only serialization struct using json.RawMessage for Result.
• Decode Result via json.Decoder + UseNumber() so numeric leaves become json.Number.
• Add a unit test ensuring large-int result round-trips preserve exact value and marshaled JSON bytes remain identical.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
message/content.go	Decode FunctionResultContent.Result using UseNumber() via a json.RawMessage intermediary to preserve large-integer precision.
message/content_test.go	Add a round-trip test that asserts large integer results and re-marshaled JSON remain unchanged.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[PratikDhanave]

Good catch — fixed in c7d6580: UnmarshalJSON now resets t.Result to nil when tmp.Result is empty and t.Error to nil when tmp.Error is empty, so stale values on a non-zero receiver no longer stick. Added TestFunctionResultContentUnmarshalResetsStaleFields to lock the behavior.

[github-actions]

Parity Review: ✅ Approved

This PR fixes a JSON round-trip precision bug in FunctionResultContent.UnmarshalJSON by switching to json.NewDecoder(...).UseNumber() so that large integers (above 2^53) are not silently corrupted to float64.

Scope: Internal serialization behavior only. No exported types, fields, or method signatures changed. The Result any field type is unchanged; only the decoded representation of numeric JSON values improves from lossy float64 to exact json.Number.

Cross-repo parity assessment:

• .NET: Uses JsonElement (System.Text.Json) for tool-result payloads, which preserves numeric values without lossy narrowing to double. The Go fix aligns Go behavior with this .NET property.
• Python: Tool results are handled as raw Python objects/dicts; Python's json module decodes integers as int natively (no float truncation for whole numbers), so Python already has the correct behavior by default.

This change closes a Go-specific gap relative to both .NET and Python. It is a correctness fix, not a divergence. No parity issues found.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by Go API Consistency Review Agent · 24.2 AIC · ⌖ 5.58 AIC · ⊞ 5.9K · ◷