[Hardik K (hardikkaurani)]

Summary of Changes

Closes #352

While _coerce_generic() and _can_reconstruct() in durabletask/serialization.py support type-directed coercion for dict / Mapping, tuple, and list / Sequence containers, they previously omitted support for collections.abc.MutableMapping and collections.abc.MutableSequence.

As a result:

• converter.can_reconstruct() returned False for annotations such as MutableMapping[str, MyModel] and MutableSequence[MyModel].
• Inbound type discovery in type_discovery.activity_input_type and orchestrator_input_type discarded these annotations and returned None, causing activities and orchestrators to receive uncoerced dictionaries and lists instead of typed model instances.
• Inbound payloads deserialized with target_type=MutableMapping[str, MyModel] or MutableSequence[MyModel] bypassed element-wise coercion.

This change:

• Adds MutableMapping and MutableSequence to _can_reconstruct(), enabling recursive model reconstructability checks when their value or element types are reconstructable.
• Extends _coerce_generic() to recursively coerce items for MutableMapping and MutableSequence annotations.
• Adds comprehensive round-trip deserialization, type discovery, and activity executor regression tests for both container types.
• Documents MutableMapping and MutableSequence container support in durabletask/serialization.py and the core and Azure Managed changelogs.

Changes Across Commits

1. Commit 1: fix(serialization): support MutableMapping in can_reconstruct and _coerce_generic

   • Import MutableMapping from collections.abc and add it to _can_reconstruct() and _coerce_generic().

2. Commit 2: fix(serialization): support MutableSequence in can_reconstruct and _coerce_generic

   • Import MutableSequence from collections.abc and add it to _can_reconstruct() and _coerce_generic().

3. Commit 3: test(serialization): verify can_reconstruct and deserialization with MutableMapping

   • Add unit tests verifying can_reconstruct() and round-trip deserialization for MutableMapping[str, Model].

4. Commit 4: test(serialization): verify can_reconstruct and deserialization with MutableSequence

   • Add unit tests verifying can_reconstruct() and round-trip deserialization for MutableSequence[Model].

5. Commit 5: test(worker): verify type discovery and input reconstruction for MutableMapping and MutableSequence

   • Add worker activity execution tests verifying that activities annotated with MutableMapping[str, Order] and MutableSequence[Order] correctly receive reconstructed dataclass instances.

6. Commit 6: docs(serialization): document MutableMapping and MutableSequence container support

   • Update docstring in durabletask/serialization.py and document the change in CHANGELOG.md and durabletask-azuremanaged/CHANGELOG.md.

Verification

• pytest tests/durabletask/test_serialization.py tests/durabletask/test_type_discovery.py tests/durabletask/test_data_converter_roundtrip.py (191/191 passed)
• ruff check . (All checks passed)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Hardik K (hardikkaurani)]

Hi maintainers, Bernd Verst (@berndverst) and andystaples

I've opened this PR to address #352 by extending type-directed reconstruction to support MutableMapping and MutableSequence annotations. These container types are now recognized by can_reconstruct() and recursively coerce their values or elements into the expected model types.

I've also added regression coverage for serialization round-trips, type discovery, and activity input reconstruction, along with the relevant documentation and changelog updates.

Validation is passing: 191 tests passed, and ruff check . reports no issues.

Whenever you have a moment, I'd appreciate your review and feedback. Thank you!

[Bernd Verst (berndverst)]

Hardik K (@hardikkaurani) we will not accept PRs for issues that have been opened by the PR author just moments earlier.

An issue at minimum requires community discussion or triage from maintainers. No unsolicited PRs please.

We already went over this with your previous contribution: #310 (comment)

The issue requires triage from andystaples or myself (Bernd Verst (@berndverst)) before we will accept a PR.

[Hardik K (hardikkaurani)]

Hi Bernd Verst (@berndverst) and andystaples

Thanks for clarifying. I understand your contribution process and acknowledge that I should have waited for maintainer triage and community discussion before opening this PR.

I'll keep this in mind for future contributions and avoid submitting PRs for issues that haven't been discussed or triaged first.

Apologies for overlooking this, and thanks for taking the time to clarify the expectations.