Fix: Exclude computed fields during pydantic MP serialization

[SkiHatDuckie]

Summary

See the linked issue for more details. In short, fields with the@computed_field decorator are included in model_dump (and similar) by default, but are then treated as extra fields when passed to model_validate, leading to duplicates appearing in the final deserialized object.

Details

• Set exclude_computed_fields=True in Serializer.to_dict_pydantic and .to_sequence_pydantic
• Remove pytest.mark.xfail from test_encode_decode_generative

Test Plan

tox -e test-unit -- tests/unit/utils/test_encoding.py

Related Issues

• Resolves serializer.deserialize(serialized) duplicate the last dict data #446
  • Alternative solution to [Draft]remove computed_field from total_tokens #448

---

• "I certify that all code in this PR is my own, except as noted below."

Use of AI

• Includes code generated or substantially modified by an AI agent
• Includes tests generated or substantially modified by an AI agent

NOTE: the Generated-by or Assisted-by trailers should be used in git commit messages when code or tests were generated or substantially modified by an AI agent, as described in the project's DEVELOPING.md file.

---

git log

commit 4c59acb
Author: SkiHatDuckie SkiHatDuckie@gmail.com
Date: Wed Jun 24 15:02:04 2026 -0400

Exclude computed fields during pydantic model dump

Signed-off-by: SkiHatDuckie <SkiHatDuckie@gmail.com>

---

Signed-off-by: SkiHatDuckie SkiHatDuckie@gmail.com

[sjmonson]

LGTM

[mergify]

Queued — the merge queue status continues in this comment ↓.

[dbutenhof]

I suppose my concern would be if we're ever using this in a context where we want computed fields to be serialized (e.g., for a report) -- presumably that'd never be in a context where we're going to re-deserialize and encounter the problem, but this is one of those places where it's hard to get a full call dependency graph; and if Sam thinks this is safe, I'll throw on my +1 on the basis that, at least in isolation, the change looks OK.

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-06-24 19:34 UTC · Rule: default · triggered by merge protections
• ✅ Checks passed · on draft merge queue: queuing main (15a55a3) and #845 together #847
• ✅ Merged — 2026-06-24 20:02 UTC · at 4c59acb978d7fa3264d95d99a52873ec977e36c8 · squash

This pull request spent 28 minutes 23 seconds in the queue, including 28 minutes 4 seconds running CI.

Required conditions to merge

• any of [🛡 GitHub repository ruleset rule Merge Requirements]:
  • check-success = @github-actions/quality (3.10) / type-checks
  • check-neutral = @github-actions/quality (3.10) / type-checks
  • check-skipped = @github-actions/quality (3.10) / type-checks
• any of [🛡 GitHub repository ruleset rule Merge Requirements]:
  • check-success = @github-actions/quality (3.10) / precommit-checks
  • check-neutral = @github-actions/quality (3.10) / precommit-checks
  • check-skipped = @github-actions/quality (3.10) / precommit-checks
• any of [🛡 GitHub repository ruleset rule Merge Requirements]:
  • check-success = @github-actions/quality (3.10) / quality-checks
  • check-neutral = @github-actions/quality (3.10) / quality-checks
  • check-skipped = @github-actions/quality (3.10) / quality-checks
• any of [🛡 GitHub repository ruleset rule Merge Requirements]:
  • check-success = @github-actions/tests (3.10) / e2e-tests
  • check-neutral = @github-actions/tests (3.10) / e2e-tests
  • check-skipped = @github-actions/tests (3.10) / e2e-tests
• any of [🛡 GitHub repository ruleset rule Merge Requirements]:
  • check-success = @github-actions/tests (3.10) / integration-tests
  • check-neutral = @github-actions/tests (3.10) / integration-tests
  • check-skipped = @github-actions/tests (3.10) / integration-tests
• any of [🛡 GitHub repository ruleset rule Merge Requirements]:
  • check-success = @github-actions/tests (3.10) / unit-tests
  • check-neutral = @github-actions/tests (3.10) / unit-tests
  • check-skipped = @github-actions/tests (3.10) / unit-tests
• any of [🛡 GitHub repository ruleset rule Merge Requirements]:
  • check-success = @github-actions/update-description
  • check-neutral = @github-actions/update-description
  • check-skipped = @github-actions/update-description

[sjmonson]

I suppose my concern would be if we're ever using this in a context where we want computed fields to be serialized (e.g., for a report)

Had this thought at first but the title/description is misleading. This only changes the encoding code which is used to pass objects from one process to another.

[dbutenhof]

I suppose my concern would be if we're ever using this in a context where we want computed fields to be serialized (e.g., for a report)

Had this thought at first but the title/description is misleading. This only changes the encoding code which is used to pass objects from one process to another.

Yeah, that was the usage I found -- but there was a callback protocol that broke the call chain and I wasn't 100% certain we couldn't get there from somewhere else... though it seemed improbable. I'm reassured that you're comfortable with that diagnosis.