[Hardik K (hardikkaurani)]

Resolves #222.

Summary

The protobuf InstanceQuery message defines field 4 taskHubNames (repeated google.protobuf.StringValue). While instance_id_prefix was previously added to OrchestrationQuery, filtering orchestration queries by task hub names was still missing.

This change adds task_hub_names to OrchestrationQuery and serializes it in build_query_instances_req() to align with client query capabilities across SDKs.

Changes

1. durabletask/client.py:

   • Added task_hub_names: list[str] | None = None to OrchestrationQuery.
   • Backward compatibility and existing parameter order are fully preserved.

2. durabletask/internal/client_helpers.py:

   • In build_query_instances_req(), serialized task_hub_names into InstanceQuery.taskHubNames as wrappers_pb2.StringValue.

3. tests/durabletask/test_batch_actions.py:

   • Added test_orchestration_query_serializes_task_hub_names to verify taskHubNames protobuf serialization.
   • Added test_orchestration_query_serializes_task_hub_names_and_instance_id_prefix covering combined filter queries.
   • Updated test_orchestration_query_preserves_positional_argument_order to verify default behavior when fields are omitted.

4. CHANGELOG.md:

   • Documented OrchestrationQuery.task_hub_names under Unreleased.

Validation

• Unit tests for query filter serialization pass cleanly.
• Strict Pyright type check passes with 0 errors.
• Default query behavior remains fully backward-compatible.

[Hardik K (hardikkaurani)]

Hello Bernd Verst (@berndverst),

I have submitted this pull request to resolve issue #222 by adding task_hub_names to OrchestrationQuery and serializing it through build_query_instances_req via wrappers_pb2.StringValue.

Positional argument order and backward compatibility for existing query instances are maintained, unit test coverage has been added in tests/durabletask/test_batch_actions.py, and strict Pyright type checking passes with zero errors.

Please review when convenient and let me know if any adjustments are desired.

[Copilot]

🟢 Approval recommended

The additive change preserves compatibility, matches the protobuf contract, and includes focused regression coverage.

No open issues 🎉

What changed in this PR

Adds task hub filtering to orchestration queries, completing the remaining filter support requested in #222 while preserving existing constructor argument order.

Changes:

• Adds task_hub_names and serializes it into the existing protobuf field.
• Tests task hub filtering alone and alongside instance ID prefixes.
• Documents the new capability under Unreleased.

File	Description
tests/​durabletask/​test_batch_actions.py	Adds serialization and compatibility assertions.
durabletask/​internal/​client_helpers.py	Serializes task hub names into query requests.
durabletask/​client.py	Adds the optional task hub filter.
CHANGELOG.md	Documents the new query capability.

_{Review effort: Balanced}

[Hardik K (hardikkaurani)]

Hi Bernd Verst (@berndverst) and andystaples,

Following up on this PR when convenient. It adds the task hub name filter to OrchestrationQuery (completing #222) with backwards compatibility and full Pyright type check verification. Copilot code review has also recommended approval. Looking forward to your thoughts or feedback. Thank you!

[Bernd Verst (berndverst)]

This PR appropriately addresses the remaining portion of #222, following the Durable Task .NET SDK precedent while retaining the existing Python API conventions. Instance-ID-prefix support is already present in the base branch; this PR adds task-hub filtering. No blocking correctness, compatibility, or API-design issues were identified in commit bd0a87b.

.NET precedent and Python fit

Area	.NET implementation	Assessment of this PR
Public API	OrchestrationQuery exposes optional IEnumerable<string>? TaskHubNames and string? InstanceIdPrefix.	task_hub_names: list[str] | None = None is appropriate: it matches the issue and Python's existing runtime_status collection convention. There is no need to copy .NET's collection abstraction literally.
Request construction	GetAllInstancesAsync assigns the prefix and adds hub names to the protobuf query when supplied.	The Python implementation is equivalent. Explicit StringValue wrappers are correct for Python's generated protobuf API; C# exposes these wrapper fields more transparently.
Execution model	Both the gRPC client and the in-process client shim forward filters to the backend rather than filtering results locally.	The PR follows that precedent without introducing client-side filtering or cross-hub aggregation.

The compatibility choices are also sound:

• Appending the field is preferable to copying .NET's parameter order. All six existing positional arguments retain their meanings.
• Omitted and empty hub lists preserve the previous wire request. Neither emits a hub restriction. Supplied names retain their order and values; no unsupported normalization or deduplication is introduced.
• Both sync and async paths receive the feature. They rebuild requests through the same helper on every page, preserving both filters alongside continuation tokens. Azure Managed clients inherit these paths without requiring overrides.

Non-blocking improvements

Strengthen the regression coverage in test_batch_actions.py. The new cases correctly cover hub names alone and combined with a prefix. Useful additions would cover None versus [], a six-positional-argument constructor call with a nonempty prefix, and filter preservation across paginated sync/async calls. The current positional test supplies only five arguments, so it does not protect the prefix's existing position.

Keep the backend-support boundary clear. This PR establishes client/protocol parity, not universal cross-hub query support. In particular, the in-memory backend does not apply taskHubNames; its behavior cannot demonstrate actual hub isolation. Live backend enforcement remains unverified. A short API note about backend-dependent support would be helpful, but implementing multi-hub behavior in the test backend should not block this narrowly scoped PR.

[Bernd Verst (berndverst)]

Hardik K (@hardikkaurani) can you please resolve the merge conflicts?

[Hardik K (hardikkaurani)]

Bernd Verst (@berndverst) Hi Bernd, I resolved the merge conflict and updated the PR with merge commit 1f542c4. The conflict was limited to CHANGELOG.md; the current upstream Unreleased fixes and this PR's task_hub_names entry are both retained. I also ran the focused query serialization tests: 18 passed. The repository's strict Pyright session is pinned to Python 3.10, which is not installed in my local environment, so that validation will run in CI. Could you please take another look when you have a moment? Thank you!

[Bernd Verst (berndverst)]

From me (and my agents) to you (and your agents): thanks for the contribution Hardik K (@hardikkaurani). LGTM