[Internal] DTS: Removes dead code and refactors to manual JSON deserialization

[Meghana-Palaparthi]

Pull Request Template

Description

This pull request refactors the distributed transaction response and operation result handling in the Cosmos DB SDK. The main focus is on removing dependencies on System.Text.Json.Serialization attributes and reflection-based deserialization, instead implementing explicit JSON parsing logic. Additionally, error message and tracing fields are removed from the public API surface and internal data flow, simplifying the object model.

Serialization and Deserialization Refactoring

• Removed all System.Text.Json.Serialization attributes (such as [JsonInclude], [JsonPropertyName], [JsonIgnore], and [JsonConstructor]) from DistributedTransactionOperationResult and replaced reflection-based deserialization with a manual, case-insensitive property lookup and assignment in the new FromJson method. (DistributedTransactionOperationResult.cs)
• Added a new helper method TryGetProperty for case-insensitive property lookup when parsing JSON elements. (DistributedTransactionOperationResult.cs)
• Updated the deserialization logic in DistributedTransactionResponse to use the new explicit parsing methods instead of relying on System.Text.Json attributes. (DistributedTransactionResponse.cs) [1] [2]

Error Message and Tracing Cleanup

• Removed the ErrorMessage property and associated logic from DistributedTransactionResponse and related constructors, as well as the corresponding test assertions. (DistributedTransactionResponse.cs, DistributedTransactionResponseTests.cs) [1] [2] [3] [4] [5]
• Removed the Trace and ActivityId fields from both DistributedTransactionResponse and DistributedTransactionOperationResult, and eliminated their propagation through constructors and methods. (DistributedTransactionResponse.cs, DistributedTransactionOperationResult.cs) [1] [2] [3] [4] [5]

Public API Simplification

• Changed several properties in DistributedTransactionOperationResult (such as SessionToken, PartitionKeyRangeId, and SubStatusCode) from public to internal, further restricting their visibility and clarifying the public API. (DistributedTransactionOperationResult.cs)

Test Adjustments

• Updated tests to match the new deserialization logic and removed checks for properties that no longer exist (such as SubStatusCodeValue). (DistributedTransactionResponseTests.cs) [1] [2]

These changes collectively improve maintainability, reduce reliance on reflection and serialization attributes, and clarify the SDK's public and internal APIs.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• [] New feature (non-breaking change which adds functionality)
• [] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [] This change requires a documentation update

Closing issues

To automatically close an issue: closes #IssueNumber

Changelog

• I have added a changelog entry under ### Unreleased in changelog.md
  for the user-facing impact of this change.
• No changelog entry is required because this PR is one of:
  documentation-only, test-only, CI / build-only, or a pure internal refactor
  with no observable customer impact.

If the second box is checked, briefly justify here:

Feature isn't public yet.

[kushagraThapar]

Thanks for the cleanup, @Meghana-Palaparthi — the manual JSON deserializer is the right shape and aligns nicely with what TransactionalBatchOperationResult, Java's BatchResponseParser, and Python's batch-response paths already do (no STJ attributes, direct property walks). The public→internal demotions for SessionToken / PartitionKeyRangeId / SubStatusCode / ActivityId / Trace also bring DTS in line with TransactionalBatchOperationResult.cs:94,99,104, which I think is the right consolidation.

Approving since this is [Internal] and there are no shipped customers yet. I've left a few inline observations on correctness fidelity vs the old JsonSerializer.Deserialize<T> path that would be worth picking up in a follow-up PR — especially the InvalidOperationException leak from EnumerateObject() and the silent-default behavior on numeric type mismatches. These are subtle behavior changes customers won't see today, but the DTS team is likely to hit them during internal testing.

None of the inline items block this PR — they're all opportunities for a small fast-follow.

[kushagraThapar]

LGTM, thanks @Meghana-Palaparthi

[github-actions]

📝 Changelog reminder (non-blocking)

This PR touches shipped source but does not appear to update the
corresponding changelog.md.

Touched (and missing entry for):

• Microsoft.Azure.Cosmos/src/** ⇒ expected an entry in changelog.md (### Unreleased)

How to decide

Use the rubric in .github/copilot-instructions.md ("Changelog
classifier") or in CONTRIBUTING.md ("Changelog entry"). Quick
version:

• Customer-observable change (behavior, perf, memory, API) ⇒ add an entry, even if the PR is [Internal].
• Test-only / CI-only / doc-only / pure-internal-refactor with zero customer-observable effect ⇒ no entry, add the no-changelog-needed label to silence this check.
• Unsure? Default to adding a one-line entry under #### Other Changes. Reviewer will adjust.

This check is non-blocking — merge is not gated on it. The
reviewer is responsible for the final classification.

[kushagraThapar]

LGTM, thanks @Meghana-Palaparthi