💥 Standalone Activities support by maciejdudko · Pull Request #2029 · temporalio/sdk-typescript

maciejdudko · 2026-04-28T16:30:17Z

💥 Breaking change

This PR alters Activity Info interface in backward-incompatible way by making workflowExecution, workflowNamespace and workflowType properties optional. As long as Standalone Activities are not being used, it is safe to use ! to remove type errors, however the recommended migration path is to check the inWorkflow property and handle both cases - this way the activity can be run in standalone context.

What was changed

Implemented support for Standalone Activities.

Telemetry support will be done separately, see #2031

Why?

Feature request: temporalio/features#706

Checklist

Closes [Feature Request] Support standalone activities #1851
How was this tested:

New test file test-standalone-activities.ts
New tests added to test-async-completion.ts

dandavison · 2026-04-28T18:13:38Z

+        throw failedErr;
+      }
+    }
+  }


It looks like this long-polling loop will fail to wait for longer than the server's long-poll timeout due to not handling DEADLINE_EXCEEDED. Can you compare to the implementations in Go and Python and add an integration test that demonstrates it can wait for longer than the server timeout, and for longer than the per-attempt client-side deadline? And also that it responds correctly when the activity is cancelled on the server.

Python:

while True: try: res = await self._client.workflow_service.poll_activity_execution( req, retry=True, metadata=rpc_metadata, timeout=rpc_timeout, ) if res.HasField("outcome"): self._known_outcome = res.outcome return except RPCError as err: if err.status == RPCStatusCode.DEADLINE_EXCEEDED: # Deadline exceeded is expected with long polling; retry continue elif err.status == RPCStatusCode.CANCELLED: raise asyncio.CancelledError() from err else: raise except asyncio.CancelledError: raise

Can you also check that activity cancellation is handled correctly in this loop?

The server behavior for polling timeout is to return empty response. This is handled correctly. The code throws exception on client-side deadline, but it could be argued it's the expected behavior - we can revisit is some other time, though it does match behavior of workflow result polling. Client-side cancellation is handled correctly.

Added tests to verify long long polling and client-side cancellation.

Sushisource

Overall making sense but we need to find a way to provide better type safety

Sushisource

LMK if this is ready for final review or not and I can make a last pass

maciejdudko · 2026-04-30T04:42:34Z

@Sushisource PR is ready for final review.

Sushisource

Looking good on my end but @mjameswh or @chris-olszewski should approve too

Sushisource · 2026-04-30T16:47:43Z

+      idConflictPolicy: encodeActivityIdConflictPolicy(input.options.idConflictPolicy),
+      searchAttributes: { indexedFields: searchAttributes },
+      header: input.headers,
+      userMetadata: await encodeUserMetadata(this.dataConverter, input.options.summary, undefined),


Ah, I guess you can only set them from inside the activity? We should support it in both places, but can be a follow up PR. Let's make sure we track it.

chris-olszewski

Lgtm just minor suggestions that are not blocking

chris-olszewski · 2026-04-30T17:15:00Z

+   *
+   * @experimental Standalone Activities are experimental. APIs may be subject to change.
+   */
+  readonly inWorkflow: boolean;


Non-blocking just since this is currently experimental, but making Info enforce that inWorkflow: true implies that workflowExecution etc are present would be nice

e.g.

type Info = BaseInfo & ( | { readonly inWorkflow: true; readonly workflowExecution: { workflowId: string; runId: string }; readonly workflowNamespace: string; readonly workflowType: string; readonly activityRunId?: undefined } | { readonly inWorkflow: false; readonly activityRunId: string; readonly workflowExecution?: undefined; readonly workflowNamespace?: undefined; readonly workflowType?: undefined } );

This won't really work in a way that's helpful to the users, because ActivityContext.current().info still has to be the most general type and TS compiler doesn't support type assertions on this.

chris-olszewski · 2026-04-30T17:33:59Z

-type ErrorDetailsName = `temporal.api.errordetails.v1.${keyof typeof temporal.api.errordetails.v1}`;
-type FailureName = `temporal.api.failure.v1.${keyof typeof temporal.api.failure.v1}`;
+export type ErrorDetailsName = `temporal.api.errordetails.v1.${keyof typeof temporal.api.errordetails.v1}`;
+export type FailureName = `temporal.api.failure.v1.${keyof typeof temporal.api.failure.v1}`;


I don't believe this needs to be made public

Suggested change

export type FailureName = `temporal.api.failure.v1.${keyof typeof temporal.api.failure.v1}`;

type FailureName = `temporal.api.failure.v1.${keyof typeof temporal.api.failure.v1}`;

It's not public, just privately exported within package. It's so it can be used in activity-client.ts.

chris-olszewski · 2026-04-30T17:37:41Z

+        for (const entry of getGrpcStatusDetails(err) ?? []) {
+          if (!entry.type_url || !entry.value) continue;
+          if (
+            (trimGrpcTypeUrl(entry.type_url) as ErrorDetailsName) ===


Just to be more honest with the cast

Suggested change

(trimGrpcTypeUrl(entry.type_url) as ErrorDetailsName) ===

(trimGrpcTypeUrl(entry.type_url) as ErrorDetailsName | '') ===

chris-olszewski · 2026-04-30T17:53:59Z

 function getSchedulingWorkflowHandle(): WorkflowHandle {
  const { info, client } = Context.current();
+  if (!info.inWorkflow) {
+    throw new Error('Not in workflow');


Not major, but we usually throw IllegalStateError when attempting to use workflow only code in non-workflow contexts

maciejdudko requested a review from a team as a code owner April 28, 2026 16:30

dandavison reviewed Apr 28, 2026

View reviewed changes

Comment thread packages/client/src/activity-client.ts Outdated

Sushisource reviewed Apr 28, 2026

View reviewed changes

maciejdudko added 4 commits April 29, 2026 13:43

Standalone Activities support

bb01c19

Fixed circular dependency build issue

4fed7e7

Addressed PR comments

5c3700b

Added TypedActivityClient

8a7d1f2

maciejdudko force-pushed the standalone-activities branch from 9cd8d9e to 8a7d1f2 Compare April 29, 2026 17:46

maciejdudko added 3 commits April 29, 2026 16:19

Addressed PR comments

e97ff3b

Addressed PR comments

e0aa203

Addressed PR comments

5d2fc6b

Sushisource reviewed Apr 29, 2026

View reviewed changes

Comment thread packages/client/src/activity-client.ts

Comment thread packages/client/src/activity-client.ts Outdated

maciejdudko added 3 commits April 29, 2026 23:44

Addressed PR comments

ced47ed

Addressed PR comments, added experimental annotations

c5b219b

Linter fixes

2c9489e

maciejdudko mentioned this pull request Apr 30, 2026

Fix activity/cancel_try_cancel/feature.ts after breaking change in Activity Info temporalio/features#810

Merged

maciejdudko requested review from Sushisource and dandavison April 30, 2026 04:42

Fixed test suite teardown

371ded4

Sushisource approved these changes Apr 30, 2026

View reviewed changes

chris-olszewski approved these changes Apr 30, 2026

View reviewed changes

maciejdudko changed the title ~~Standalone Activities support~~ 💥 Standalone Activities support Apr 30, 2026

maciejdudko mentioned this pull request Apr 30, 2026

[Feature Request] Telemetry support for Standalone Activities #2031

Open

maciejdudko merged commit 0e3b127 into temporalio:main Apr 30, 2026
69 of 77 checks passed

maciejdudko deleted the standalone-activities branch April 30, 2026 19:20

	export type FailureName = `temporal.api.failure.v1.${keyof typeof temporal.api.failure.v1}`;
	type FailureName = `temporal.api.failure.v1.${keyof typeof temporal.api.failure.v1}`;

	(trimGrpcTypeUrl(entry.type_url) as ErrorDetailsName) ===
	(trimGrpcTypeUrl(entry.type_url) as ErrorDetailsName \| '') ===

Conversation

maciejdudko commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

💥 Breaking change

What was changed

Why?

Checklist

Uh oh!

dandavison Apr 28, 2026 • 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!

Uh oh!

Sushisource left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Sushisource left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

maciejdudko commented Apr 30, 2026

Uh oh!

Sushisource left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chris-olszewski left a comment

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!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

maciejdudko commented Apr 28, 2026 •

edited

Loading

dandavison Apr 28, 2026 •

edited

Loading