Standalone activity by dandavison · Pull Request #1138 · temporalio/sdk-python

dandavison · 2025-10-01T18:09:40Z

To test:

In the server repo (using branch main)

make start
temporal operator namespace create -n default

Then in sdk-python, checkout this branch and

git submodule update --init --recursive
uv run poe build-develop
uv run pytest -E localhost:7233 tests/test_activity.py

See

Note

Introduces standalone activity support across SDK types and API surfaces.

Updates activity.Info: adds namespace, makes workflow_* fields optional with in_workflow helper, adds activity_run_id, and switches metrics/logging to use namespace
Adds ActivityDefinition.get_name_and_result_type utility for resolving activity name/result type from callables
Extends API: new ActivityExecutionOutcome, ActivityExecutionInfo, and ActivityExecutionListInfo messages; exports new activity enums (ActivityExecutionStatus, ID reuse/conflict policies)
Adds error detail ActivityExecutionAlreadyStartedFailure
Exposes WorkflowService requests/responses for standalone activities: start, describe, list/count, poll, request cancel, terminate, delete, and related operations

^{Written by Cursor Bugbot for commit 904c04f. This will update automatically on new commits. Configure here.}

bergundy · 2025-10-01T20:58:38Z

+ self._id_or_token = ActivityIDReference(activity_id=id, run_id=run_id)
+ self.run_id = run_id
+
+ # TODO: do we support something like `follow_runs: bool`?


No need there's no concept of an execution chain for activities.

bergundy · 2025-10-01T20:59:32Z

+ handle = await self.start_activity(*args, **kwargs)
+ return await handle.result()
+
+ async def list_activities(


Would be interesting to see how we can model this to return both workflow and standalone "client" activities.

I've made the iterator yield Union[ActivityExecution, WorkflowActivityExecution]. Those two dataclasses share a few fields.

bergundy · 2025-10-01T21:00:12Z


+ # - TODO: Overloads for no-param, single-param, multi-param
+ # - TODO: Support sync and async activity functions
+ async def start_activity(


Also need execute_activity but we can leave that for later.

Actually execute_activity is already present below.

bergundy · 2025-10-01T21:01:29Z

+
+
 @dataclass(frozen=True)
 class AsyncActivityIDReference:


Consider deprecating and renaming to WorkflowActivityIDReference.

Or merging the two reference types where workflow_id becomes an optional field.

I've merged them into ActivityIDReference and retained the AsyncActivityIDReference name as an alias.

bergundy · 2025-10-01T21:38:38Z

+ """Handle representing an activity started by a workflow."""
+
+ def __init__(
+ self, client: Client, id_or_token: Union[AsyncActivityIDReference, bytes]


This should work with any activity IMHO.

Agreed. The PR:
Makes get_async_activity_handle work for Standalone Activities and Workflow Activities. This is essentially a client appropriate for the "owner" of the activity, permitting manual completion/fail/cancellation/heartbeating
Introduces Client.get_activity_handle for SA only. This is a cliet appropriate for the caller of the activity: describe, poll, request cancellation, etc

bergundy · 2025-10-01T21:39:51Z

+ self._id_or_token = id_or_token
+
+
+WorkflowActivityHandle = AsyncActivityHandle


This will also need pause, reset, etc...

I think we still want AsyncActivityHandle because you can obtain one with a token and can't do anything else with the token but issue completion requests.

I've added implementations of pause / unpause / reset to the new ActivityHandle for SAs.
The existing AsyncActivityHandle is unperturbed by this PR: it just gains a constructor for SAs.

bergundy · 2025-10-01T21:40:11Z

+ """
+ raise NotImplementedError
+
+ # TODO:


Also TODO: all of the async completion methods.

You mean heartbeat, complete, fail, and report_cancellation, right? Those are all inherited from _BaseActivityHandle.

I'm on the fence whether we want to expose these methods on the activity handle as opposed to having the async completion handle as a separate concept. The use cases are different for the two.

Yes, I also changed direction here: they are now on AsyncActivityHandle, for SA as they are for WA.

bergundy · 2025-10-01T21:41:14Z

 )


+# TODO: This name is suboptimal now. We could deprecate it and introduce WorkflowActivityHandle as a


Yeah, let's do that. Which means that you would have to accept a WorkflowActivityHandle where you accept AsyncActivityHandle.

I've renamed, and am retaining the old name as an alias to the same class object.

bergundy · 2025-10-01T21:42:26Z


-class AsyncActivityHandle:
- """Handle representing an external activity for completion and heartbeat."""
+class _BaseActivityHandle:


I would consider just duplicating instead of inheriting but don't have a strong opinion.

cretz · 2025-10-13T17:22:07Z

 )

+ @classmethod
+ def get_name_and_result_type(


If we're extracting this common logic out of workflow_instance.py, can we update workflow_instance.py use this too? Also, then can we get rid of must_from_callable and inline it into this method since it won't be called anywhere anymore?

cretz · 2025-10-13T17:24:10Z

+ # - TODO: Support sync and async activity functions
+ async def start_activity(
+ self,
+ activity: Union[str, Callable[..., Awaitable[ReturnType]]],


I think when we get to the overloads, this final form may not make sense to use the generic

cretz · 2025-10-13T17:25:27Z

 )


+class IdReusePolicy(IntEnum):


I think each top-level thing should have its own enumerate here. It doesn't make sense to have workflow ID reuse policy and not activity ID reuse policy. Same for ID conflict policy. It makes more sense from a user POV not to pretend like this is a common ID reuse policy when it is not (nor do we need it to be).
We should not eschew consistency just because we may have a NexusOperationIdReusePolicy one day (and we'll be happy we kept them separate if they diverge). This is no different than cancellation type or any of these others.

cretz · 2025-10-13T17:27:06Z

+ retry_policy: Optional[temporalio.common.RetryPolicy] = None,
+ search_attributes: Optional[
+ Union[
+ temporalio.common.SearchAttributes,


IMO we don't need to accept this deprecated form of search attributes for newer API, but it's not harmful

Thanks, I meant to remove that. Removed.

cretz · 2025-10-13T17:31:11Z

+
+ def list_activities(
+ self,
+ query: Optional[str] = None,


Can you confirm whether we expect a query specifically saying activity kind is "standalone" at this time so that when we add non-standalone one day it doesn't surprise users?

cretz · 2025-10-13T18:30:09Z

+ TIMED_OUT = 6 # ACTIVITY_EXECUTION_STATUS_TIMED_OUT
+
+
+class PendingActivityState(IntEnum):


I think this also may make sense in the client module

cretz · 2025-10-13T19:11:02Z

I think we should go ahead and put here the expected changes to activity runtime. Specifically I assume all workflow_-prefixed fields of Info will become optional. I would also recommend either a "kind" enumerate for activities, or add an is_standalone akin to is_local so users can know it's not the traditional activity.

cretz · 2025-10-13T19:11:34Z

+ namespace: str
+ """Namespace."""
+
+ workflow_id: Optional[str]


What situations would workflow ID be optional here?

cretz · 2025-10-13T19:21:04Z

+# TODO: This error class has required history event fields. I propose we retain it as
+# workflow-specific and introduce client.ActivityFailureError for an error in a standalone activity.
+# We could deprecate this name and introduce WorkflowActivityError as a preferred-going-forwards
+# alias.


I agree with behavior, but disagree with the aliasing. This specifically maps to ActivityFailureInfo in our API, I think we should keep that naming correlation (same for all failure errors). I expect similar for standalone Nexus operation failures (they don't use the named-in-proto failure messages, so they don't affect failure error things).

cretz · 2025-10-13T19:51:02Z

+ activity_id: Optional[str]
+ """Activity ID. Optional if this is an activity started from a workflow."""


In what situations is this optional? To confirm, is this not the activity ID for regular activities? We have to make sure that every value that is present on the deserialization side is present on the serialization side. So a workflow should always set this (right now it's defaulted in the constructor of the activity handle, but we can move it out if needed).

maciejdudko · 2025-10-17T16:31:34Z

I see that activity.Info was left unchanged.

How should an activity check if it's running standalone (e.g. before conditionally reading workflow ID)?
How does a standalone activity checks its own standalone-specific options? For now that would be only id_reuse_policy and id_conflict_policy as far as I can tell.

Implement list/count activities alphabetical order ActivityHandle.result Implement start_activity Update sdk-core Server isn't returning RunID yet Add activity IDs to test since they are now set in context Eliminate base serialization context class Extend tests Don't hardcode workflow IDs Fix AsyncActivityHandle TEMP: Alter manual activity tests to not require worker Skip tests globally Revert "TEMP: Alter manual activity tests to not require worker" This reverts commit 7127c0f. Assert describe returns new state after transition Fix cancellation and failure tests Cleanup Add experimental notices Workaround mypy bug Skip Standalone Activity tests in CI Only support TypedSearchAttributes

This commit updates the Python SDK standalone activity implementation to match Maciej's cross-language design specification. - ActivityIdReusePolicy → ActivityIDReusePolicy - ActivityIdConflictPolicy → ActivityIDConflictPolicy - Renamed property 'id' → 'activity_id' - Renamed property 'run_id' → 'activity_run_id' - Updated internal _id and _run_id variables accordingly - Renamed 'run_id' → 'activity_run_id' - Renamed 'schedule_time' → 'scheduled_time' - Added 'namespace' field (copied from calling client) - Removed 'state_transition_count' field - Removed the separate class; all list results now return ActivityExecution - Renamed 'run_id' → 'activity_run_id' - Renamed 'schedule_time' → 'scheduled_time' - Added 'namespace', 'close_time', 'execution_duration' fields - Removed 'state_transition_count' field - Added ActivityExecutionCountAggregationGroup class - Added 'groups' field for aggregation support - Renamed 'ret_type' → 'result_type' - Renamed 'static_summary' → 'summary' - Renamed 'static_details' → 'details' - CancelActivityInput.run_id → activity_run_id - TerminateActivityInput.run_id → activity_run_id - DescribeActivityInput.run_id → activity_run_id - Added 'wait_for_cancel_completed: bool' field - Renamed parameter 'run_id' → 'activity_run_id' - Added 'namespace: str' field - Added 'activity_run_id: str | None' field (None for workflow activities) - Added 'in_workflow' property - Made workflow_id, workflow_namespace, workflow_run_id, workflow_type optional (None for standalone activities) - Deprecated 'workflow_namespace' in favor of 'namespace' - Updated tests/test_activity.py and tests/worker/test_activity.py - Fixed temporalio/contrib/opentelemetry.py - Fixed temporalio/contrib/openai_agents/_mcp.py - GetActivityResultInput and interceptor method - would require significant refactoring of the result caching mechanism in ActivityHandle

…tivity # Conflicts: # temporalio/api/activity/v1/message_pb2.py # temporalio/api/activity/v1/message_pb2.pyi # temporalio/api/workflowservice/v1/__init__.py # temporalio/api/workflowservice/v1/request_response_pb2.py # temporalio/api/workflowservice/v1/request_response_pb2.pyi # temporalio/api/workflowservice/v1/service_pb2.py # temporalio/api/workflowservice/v1/service_pb2_grpc.py # temporalio/api/workflowservice/v1/service_pb2_grpc.pyi # temporalio/bridge/sdk-core # temporalio/bridge/services_generated.py # temporalio/bridge/src/client_rpc_generated.rs

cretz · 2026-01-14T14:37:00Z

Closing this PR in favor of a newer PR w/out the draft comments (may take a bit to get the new PR ready, so no link right away, but closing this one so mutations to the branch don't keep updating it)

dandavison force-pushed the standalone-activity branch from a1d3efe to 23df3f8Compare October 1, 2025 18:13

bergundy reviewed Oct 1, 2025
View reviewed changes

dandavison force-pushed the standalone-activity branch 3 times, most recently from e53a5c2 to 0a21bf7Compare October 8, 2025 21:47

dandavison changed the title ~~Standalone activity API sketches~~Standalone activity prototypeOct 8, 2025

dandavison force-pushed the standalone-activity branch from 07c6917 to 49ae6c3Compare October 9, 2025 15:39

dandavison mentioned this pull request Oct 9, 2025
Standalone activity prototype temporalio/sdk-rust#1031
Draft

dandavison force-pushed the standalone-activity branch 6 times, most recently from ace675c to 741603fCompare October 10, 2025 09:47

cretz reviewed Oct 13, 2025
View reviewed changes

dandavison force-pushed the standalone-activity branch 2 times, most recently from 3eccdd3 to bdb2557Compare December 19, 2025 19:54

dandavison mentioned this pull request Dec 19, 2025
Standalone activity temporalio/samples-python#270
Merged

dandavisonand others added 3 commits January 6, 2026 18:36

Update core
e0d31de

uv run poe gen-protos-docker
08dea1e

dandavison added 2 commits January 6, 2026 18:40

Modernize type annotations
83b11e7

dandavison force-pushed the standalone-activity branch 2 times, most recently from 28315b7 to 5b0294aCompare January 12, 2026 19:30

dandavison marked this pull request as ready for review January 12, 2026 19:31

dandavison requested a review from a team as a code owner January 12, 2026 19:31

dandavison changed the title ~~Standalone activity prototype~~Standalone activityJan 12, 2026

dandavison force-pushed the standalone-activity branch from 5b0294a to d60dfe6Compare January 12, 2026 19:41

Implement the rest of the spec
904c04f

dandavison force-pushed the standalone-activity branch from d60dfe6 to 904c04fCompare January 12, 2026 19:44

dandavison marked this pull request as draft January 12, 2026 19:46

cretz added 2 commits January 14, 2026 08:18

Fix Core submodule version
0be7b55

cretz closed this Jan 14, 2026

cretz mentioned this pull request Jan 28, 2026
💥 Standalone activity support #1307
Merged

		self._id_or_token = id_or_token


		WorkflowActivityHandle = AsyncActivityHandle

		)


		# TODO: This name is suboptimal now. We could deprecate it and introduce WorkflowActivityHandle as a

		TIMED_OUT = 6 # ACTIVITY_EXECUTION_STATUS_TIMED_OUT


		class PendingActivityState(IntEnum):

		activity_id: Optional[str]
		"""Activity ID. Optional if this is an activity started from a workflow."""

Uh oh!

Conversation

dandavison commented Oct 1, 2025• edited by cursor BotLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cretzOct 13, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cretzOct 13, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cretzOct 13, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maciejdudko commented Oct 17, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cretz commented Jan 14, 2026

Uh oh!

Reviewers

Assignees

dandavison commented Oct 1, 2025•
edited by cursor Bot
Loading

cretzOct 13, 2025•
edited
Loading

cretzOct 13, 2025•
edited
Loading

cretzOct 13, 2025•
edited
Loading

maciejdudko commented Oct 17, 2025•
edited
Loading