feat(sdk): workflow interceptors by chris-olszewski · Pull Request #1401 · temporalio/sdk-rust

chris-olszewski · 2026-07-14T15:33:59Z

What was changed

Workflow implementation no longer handles the conversion of outputs to payloads and instead returns WorkflowOutputValue that allows interceptors to inspect/modify outputs before serialization.
continue_as_new no longer takes reference to input since interceptors might modify/swap the input. In retrospect taking a reference was also awkward IMO.
Add WorkflowInterceptor trait and update workflow machinery to use interceptors.
add_workflow_interceptor_factory/WorkflowInterceptorFactory which constructs an named array of workflow interceptors.
WorkflowInterceptorFuture a named future that is the expected future to be produced by interceptor futures. We could expose LocalBoxFuture directly instead if we're willing to expose that 3rd party type as an external API type.

`WorkflowInterceptor`

Interceptors look like the following:

fn handle_signal<'a>(
        &'a self,
        ctx: WorkflowInterceptorContext,
        input: HandleSignalInput,
        next: WorkflowNext<
            'a,
            HandleSignalInput,
            WorkflowInterceptorFuture<'a, HandleSignalResult>,
        >,
    ) -> WorkflowInterceptorFuture<'a, HandleSignalResult> {
        next.run(input)
    }

They take a context with a subset of functionality of a workflow context, input for the operation and a next continuation that calls the next interceptor in the chain. They are always sync forcing users to do any async work in a WorkflowInterceptorFuture.

Why?

The changes to the workflow machinery and the "construction" polling are to allow the interceptor chains to not delay command creation/handler execution if there isn't any async work. This was especially apparent with sync handlers that were eagerly executed previously. Without this special handling, the existence of an interceptor chain would at least one yield point before the execution of the handler/command creation. The construction poll is our way of ensuring we drive the chain as forward as possible.

An alternative for this would be to make the interceptor API where Next would have some explicit .then methods to remove any yield points. I felt this diverged too much from all other SDKs and was generally pretty awkward to work with.

A few other decisions

We have a singular workflow interceptor trait over 2 separate ones to make registration a singular method instead of spliting inbound/outbound.
WASM interceptors have to be defined inside the component

Checklist

Closes [Feature Request] Workflow interceptors #1139
How was this tested:
See integration tests.
Any docs updates needed?
Once released should add interceptors page for the Rust SDK docs.

Sushisource

Woof that was a doozy

Sushisource · 2026-07-17T22:27:32Z

+impl ContinueAsNewInput {
+    pub(crate) fn new(input: Box<dyn Any>, options: ContinueAsNewOptions) -> Self {
+        Self {
+            decoded: DecodedInput::new(Some(input), HashMap::new()),


How can user specify headers? Needs to be extracted from options

Removed the headers field from continue as new opts so headers must be set in an interceptor now. Aligns with TS/.NET.

Sushisource · 2026-07-17T22:31:19Z

    ) -> Result<Box<dyn WorkflowInstance>, anyhow::Error> {
+        if !input.workflow_interceptor_factories.is_empty() {
+            bail!("Native workflow interceptors cannot be used with WASM workflow components");
+        }


This seems like the wrong place to fail - we will fail every time we try to execute a workflow defined in WASM rather than just failing on worker startup, which seemingly we could do and would be faster.

However, I'm not sure why this needs to be an error. If a user defines interceptors in the WASM bundle, I think we can use those and just document that native ones do not apply to WASM workflows?

I'm also not 100% clear on why native ones can't be applied to WASM workflows. I guess just extra back-and-forth glue? (To be clear, I don't object, just want to clarify).

However, I'm not sure why this needs to be an error. If a user defines interceptors in the WASM bundle, I think we can use those and just document that native ones do not apply to WASM workflows?

You're right, no need to error in this scenario.

I guess just extra back-and-forth glue?

Correct, this has been in development for long enough and the PR is large enough that I didn't feel tackling this here was necessary.

chris-olszewski · 2026-07-14T18:47:45Z

            "--release",
            "--target",
            "wasm32-unknown-unknown",
+            "--target-dir",


Not strictly necessary, but I have a custom target dir setup on my machine and allows me to run WASM tests locally without overriding it.

chris-olszewski · 2026-07-14T19:24:47Z

-        .boxed_local()
+            Ok(Box::new(output) as Box<dyn WorkflowOutputValue>)
+        };
+        ConstructionBlockedFuture::new(base_ctx, future.boxed_local()).boxed_local()


We want to ensure that if there is a sync handler with no interceptors, it is driven to completed before starting to poll an async handler.

chris-olszewski · 2026-07-22T15:34:33Z

+impl ContinueAsNewInput {
+    pub(crate) fn new(input: Box<dyn Any>, options: ContinueAsNewOptions) -> Self {
+        Self {
+            decoded: DecodedInput::new(Some(input), HashMap::new()),


Removed the headers field from continue as new opts so headers must be set in an interceptor now. Aligns with TS/.NET.

chris-olszewski · 2026-07-22T20:55:24Z

+
+pub(crate) enum NexusResultFuture {
+    Raw(Shared<WFCommandFut<NexusOperationResult, ()>>),
+    Intercepted(Shared<LocalBoxFuture<'static, NexusOperationResult>>),


On second thought I removed this entirely since the final shape of calling nexus operations hasn't stabilized.

chris-olszewski · 2026-07-23T14:30:26Z

+}
+
+/// Creates a fresh interceptor collection for each workflow instance.
+pub trait WorkflowInterceptorFactory: Send + Sync + 'static {


If this took some param that provided context about the workflow

Meant to do that, but totally forgot which did make it pointless.

Updated to now take a vec of WorkflowInterceptorConstructors which are wrappers around Fn(&WorkflowContextView) -> WorkflowInterceptor. Only have a named type so end users don't need to deal with the boxing of closures and the constructed interceptor.

chris-olszewski · 2026-07-24T13:16:55Z

        };
-        ActivityFut::running(
-            LATimerBackoffFut::new(activity.name().to_string(), payloads, opts, self.clone()),
+        let future = LATimerBackoffFut::new(activity_type, payloads, headers, opts, self.clone());


Did a quick check of Ruby and TS it seems that a regular timer with interceptors is used in both cases. We could set a timer summary that users could check?

chris-olszewski · 2026-07-25T23:54:33Z

    ) -> Result<Box<dyn WorkflowInstance>, anyhow::Error> {
+        if !input.workflow_interceptor_factories.is_empty() {
+            bail!("Native workflow interceptors cannot be used with WASM workflow components");
+        }


However, I'm not sure why this needs to be an error. If a user defines interceptors in the WASM bundle, I think we can use those and just document that native ones do not apply to WASM workflows?

You're right, no need to error in this scenario.

I guess just extra back-and-forth glue?

Correct, this has been in development for long enough and the PR is large enough that I didn't feel tackling this here was necessary.

Sushisource

I find the complexity of the whole intercepted futures system to be a bit concerning but I don't have any good alternative suggestions off the top of my head

chris-olszewski force-pushed the olszewski/workflow_interceptors_2 branch from 7b18607 to 358c765 Compare July 14, 2026 18:53

chris-olszewski marked this pull request as ready for review July 17, 2026 13:44

chris-olszewski requested a review from a team as a code owner July 17, 2026 13:44

Sushisource reviewed Jul 17, 2026

View reviewed changes

chris-olszewski mentioned this pull request Jul 21, 2026

fix(sdk): respect forced failure over completion in same poll #1417

Merged

chris-olszewski force-pushed the olszewski/workflow_interceptors_2 branch from 9020ef7 to b87ff2e Compare July 26, 2026 00:30

chris-olszewski commented Jul 26, 2026

View reviewed changes

Sushisource reviewed Jul 27, 2026

View reviewed changes

Comment thread crates/sdk/src/lib.rs

Comment thread crates/sdk/src/workflow_executor.rs

Comment thread crates/workflow/src/runtime/mod.rs

Comment thread crates/workflow/src/runtime/types.rs

chris-olszewski requested a review from Sushisource July 29, 2026 17:07

Sushisource approved these changes Jul 29, 2026

View reviewed changes

chris-olszewski added 20 commits July 29, 2026 17:04

feat(sdk): add inbound workflow interceptors

46dacd5

fix(sdk): properly support #[init] for interceptors

1b8646a

feat(sdk): workflow outbound interceptors

a223828

self review

fa371c4

use macros for caller definitions

c797b95

rebase fixups

6453c14

pr feedback: remove headers on child wfl options

e4a426b

pr feedback: move out wasm interceptor

7cbaa4a

pr feedback: small doc comment fixups

980d90f

pr feedback: better comments/names for ConstructionBlockedFuture

7b0d9b7

pr feedback: inline _unintercepted methods

7b64298

pr feedback: remove nexus special casing

3408401

pr feedback: take vec of interceptor constructors instead of factory

83ab72b

pr feedback: avoid forwarding cancel for finished futures

5b76df2

wip: respect nd futures in interceptors

1d86ffa

wip: drive interceptors until SDK will handle activations

44e0ac9

pr feedback: warn on native interceptor/wasm workflow

698a311

pr feedback: avoid cloning interceptor vec

f97cfad

pr feedback: just use routing pending state

5b002af

pr feedback: state machinify intercepted future status

ee3fadb

chris-olszewski added 3 commits July 29, 2026 17:11

pr feedback: add mutable ref for wfl interceptor constructors

2c38563

pr feedback: some comments

703365a

add changelog

c24f347

chris-olszewski force-pushed the olszewski/workflow_interceptors_2 branch from e492cce to c24f347 Compare July 29, 2026 21:11

chris-olszewski merged commit fe9f753 into main Jul 30, 2026
38 of 40 checks passed

chris-olszewski deleted the olszewski/workflow_interceptors_2 branch July 30, 2026 01:25

Conversation

chris-olszewski commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What was changed

WorkflowInterceptor

Why?

Checklist

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!

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!

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!

Sushisource left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

chris-olszewski commented Jul 14, 2026 •

edited

Loading

`WorkflowInterceptor`