Continued cleanup

Author: Sushisource

.cargo/config.toml

@@ -32,6 +32,8 @@ lint = [
     "--test",
     "manual_tests",
     "--test",
+    "wasm_workflow_tests",
+    "--test",
     "cloud_tests",
     "--test",
     "integ_runner",
@@ -53,6 +55,8 @@ lint-fix = [
     "--test",
     "manual_tests",
     "--test",
+    "wasm_workflow_tests",
+    "--test",
     "cloud_tests",
     "--test",
     "integ_runner",

.github/workflows/per-pr.yml

@@ -188,6 +188,29 @@ jobs:
           save-if: ${{ github.ref == 'refs/heads/main' }}
       - run: cargo integ-test
 
+  wasm-workflow-tests:
+    name: WASM workflow tests
+    timeout-minutes: ${{ github.ref == 'refs/heads/main' && 30 || 25 }}
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+      - uses: dtolnay/rust-toolchain@29eef336d9b2848a0b548edc03f92a220660cdb8 # stable
+        with:
+          targets: wasm32-unknown-unknown
+      - name: Install protoc
+        uses: arduino/setup-protoc@c65c819552d16ad3c9b72d9dfd5ba5237b9c906b # v3
+        with:
+          # TODO: Upgrade proto once https://github.com/arduino/setup-protoc/issues/99 is fixed
+          version: "23.x"
+          repo-token: ${{ secrets.GITHUB_TOKEN }}
+      - uses: Swatinem/rust-cache@e18b497796c12c097a38f9edb9d0641fb99eee32 # v2
+        with:
+          save-if: ${{ github.ref == 'refs/heads/main' }}
+          key: wasm-workflow-tests
+      - name: Install cargo-component
+        run: cargo install --locked cargo-component
+      - run: cargo integ-test -t wasm_workflow_tests
+
   cloud-tests:
     if: github.event.pull_request.head.repo.full_name == '' || github.event.pull_request.head.repo.full_name == 'temporalio/sdk-rust'
     name: Cloud tests

crates/sdk-core/Cargo.toml

@@ -198,6 +198,19 @@ path = "tests/manual_tests.rs"
 test = false
 required-features = ["test-utilities"]
 
+[[test]]
+name = "wasm_workflow_tests"
+path = "tests/wasm_workflow_tests.rs"
+# Prevents autodiscovery, and hence these getting run with `cargo test`. Run with
+# `cargo integ-test -t wasm_workflow_tests`. Building these requires the `wasm32-unknown-unknown`
+# target and `cargo component`, which aren't installed by default.
+test = false
+required-features = [
+  "temporalio-common/serde_serialize",
+  "test-utilities",
+  "ephemeral-server",
+]
+
 [[test]]
 name = "global_metric_tests"
 path = "tests/global_metric_tests.rs"

crates/sdk-core/tests/main.rs

@@ -25,7 +25,6 @@ mod integ_tests {
     mod schedule_tests;
     mod update_tests;
     mod visibility_tests;
-    mod wasm_workflow_tests;
     mod worker_heartbeat_tests;
     mod worker_tests;
     mod worker_versioning_tests;

…tests/integ_tests/wasm_workflow_tests.rs …es/sdk-core/tests/wasm_workflow_tests.rscrates/sdk-core/tests/integ_tests/wasm_workflow_tests.rs renamed to crates/sdk-core/tests/wasm_workflow_tests.rs crates/sdk-core/tests/integ_tests/wasm_workflow_tests.rs renamed to crates/sdk-core/tests/wasm_workflow_tests.rs

@@ -1,3 +1,10 @@
+//! Tests that exercise the WASM workflow execution path. These are kept in a separate test binary
+//! because they require `cargo component` and the `wasm32-unknown-unknown` target to build the
+//! sample components, which not every CI environment has installed.
+
+#[allow(dead_code)]
+mod common;
+
 use crate::common::CoreWfStarter;
 use std::{path::PathBuf, time::Duration};
 use temporalio_client::{UntypedWorkflow, WorkflowStartOptions};

crates/sdk/src/workflows.rs

@@ -3,3 +3,5 @@
 pub use temporalio_workflow::workflows::*;
 
 pub use crate::workflow_registry::WorkflowDefinitions;
+#[doc(inline)]
+pub use temporalio_macros::{workflow, workflow_methods};

crates/workflow/Cargo.toml

@@ -32,8 +32,9 @@ wit-bindgen = { version = "0.57.1", default-features = false, features = ["macro
 path = "../common-wasm"
 version = "0.2"
 
+[dependencies.temporalio-macros]
+path = "../macros"
+version = "0.3"
+
 [lints]
 workspace = true
-
-[dev-dependencies]
-temporalio-macros = { path = "../macros" }

crates/workflow/src/lib.rs

@@ -5,6 +5,9 @@
 extern crate self as temporalio_workflow;
 
 pub use temporalio_common_wasm as common;
+pub use temporalio_macros::{
+    init, query, run, signal, update, update_validator, workflow, workflow_methods,
+};
 
 #[doc(hidden)]
 pub mod __private {

crates/workflow/wit/README.md

@@ -1,54 +1,58 @@
 # Workflow Runtime WIT
 
-This directory defines the canonical high-level workflow guest interface for the future WASM SDK.
+This directory defines `temporal:workflow-runtime@0.1.0`, the high-level guest interface that
+workflow code targets when it is compiled to a WebAssembly component. It is intentionally separate
+from the core activation/completion protocol that worker SDKs speak to the Temporal cluster: core
+remains the worker-facing protocol, and a worker is responsible for translating core activations
+and completions into calls against this interface.
+
+## What's in here
+
+- `world.wit` — the `workflow-module` world: imports `workflow-host`, exports `workflow-guest`.
+- `guest.wit` — `workflow-guest`: the entry points the guest exports for the host to drive
+  (`list-workflows`, `instantiate-workflow`, and the `workflow-instance` resource with `activate`
+  and `poll-routine`).
+- `host.wit` — `workflow-host`: the host capabilities the guest imports (e.g. `set-current-details`,
+  `push-command`).
+- `types.wit` — shared records and variants used by both sides (init/activation/completion shapes,
+  routine kinds, terminal outcomes, etc.). Some fields are typed as `list<u8>` and carry encoded
+  protobuf messages — those proto schemas are part of the ABI; see *Stability* below.
+
+## How a workflow runs against it
+
+1. The host instantiates a workflow run by calling `instantiate-workflow` with `workflow-init`.
+2. For each activation, the host calls `activate` on the `workflow-instance` resource. The guest
+   processes the activation's jobs and reports per-job results (started routines, query responses,
+   update rejections).
+3. The guest drives its routines (main, signals, updates) by being polled — the host calls
+   `poll-routine(routine-id)` until the routine either completes or reports it made no progress.
+4. While running, the guest invokes host functions to push commands and update execution state.
+
+The guest interface is deliberately higher-level than core's activation protocol: ordering rules
+and worker bookkeeping live in the host translation layer, not in the guest contract.
 
-This is intentionally **not** the existing core activation/completion protocol. Core remains the
-worker-facing protocol for the foreseeable future, and other language SDKs will continue to use it.
-The Rust worker will translate core activations and completions into this higher-level interface.
-
-## Why this lives in `temporalio-workflow`
-
-`temporalio-workflow` is the crate that workflow implementations compile against. Checking the WIT
-in here gives the Rust runtime refactor a concrete target:
-
-- `temporalio_workflow::runtime::*` should evolve toward a direct Rust mirror of these interfaces.
-- The native Rust worker should keep calling those Rust traits directly, with no WIT serialization
-  in the hot path.
-- A future WASM backend should expose the same interface through the component model.
-
-## Layering
-
-The layers are:
-
-1. Core activation/completion protocol
-2. Native worker translation layer
-3. This WIT-shaped workflow runtime interface
-4. Workflow guest code
-
-That translation layer is where activation ordering and other core-specific details stay hidden.
-The guest interface here is deliberately higher level:
-
-- the host instantiates a workflow run
-- the host applies activation-wide context
-- the host notifies signals, cancellation, patches, updates, and operation resolutions
-- the guest polls until it blocks or terminates
+## Synchronous ABI and the WASIp3 future
 
-## Native and WASM execution
+The guest interface is synchronous: `activate` and `poll-routine` return ordinary results, and a
+routine signals "blocked" by returning `routine-poll-result.made-progress = false`. The host
+re-enters `poll-routine` after the relevant activation lands. This shape is what stable Wasmtime
+and `wit-bindgen` support today.
 
-The runtime should support two backends behind the same worker translation logic:
+When component-model async (WASIp3 / Preview 3) is stable in Wasmtime, the natural evolution is:
 
-- a native backend that invokes Rust traits directly in-process
-- a WASM backend that invokes a component implementing `workflow-module`
+- `activate` and `poll-routine` become `async func`.
+- `routine-poll-result.made-progress` and the explicit `routine-id`-keyed polling protocol can
+  go away — the host can `await` each routine directly.
 
-The goal is one logical execution model with two transport backends, not two independent workers.
+That is a breaking ABI change and will require a major-version WIT bump.
 
 ## Stability
 
-The package is published as `temporal:workflow-runtime@0.1.0` and is **not yet stable**. Until
-this is bumped to `1.0.0` any release may bump the minor version with breaking changes. Once
-external SDKs (Python, TypeScript, Go, etc.) begin compiling guest workflows against this WIT,
-breaking changes need to follow normal SemVer discipline: bump the package version, dual-export
-the old and new world from the host for a deprecation window, and document the migration path.
+The package is published as `temporal:workflow-runtime@0.1.0` and is **not yet stable**. Until it
+is bumped to `1.0.0`, any release may bump the minor version with breaking changes. Once external
+SDKs (Python, TypeScript, Go, etc.) begin compiling guest workflows against this WIT, breaking
+changes need to follow normal SemVer discipline: bump the package version, dual-export the old
+and new world from the host for a deprecation window, and document the migration path.
 
 Changes that force a major bump include:
 
@@ -57,21 +61,3 @@ Changes that force a major bump include:
 - Reordering variant cases (the discriminant order is part of the ABI).
 - Changing the proto messages encoded into `list<u8>`-typed fields (`failure`, `payload`,
   `workflow-command`, `workflow-activation`, `continue-as-new-request`).
-
-## Synchronous ABI and the WASIp3 future
-
-The current guest interface is intentionally synchronous: `activate` and `poll-routine` both
-return ordinary results, and the guest is expected to suspend by returning
-`routine-poll-result.made-progress = false`. The host then re-enters `poll-routine` after the
-relevant activation lands.
-
-This shape is what stable Wasmtime + `wit-bindgen` support today. When component-model async
-(WASIp3 / Preview 3) lands as stable in Wasmtime, the natural evolution is:
-
-- `activate` and `poll-routine` become `async func`.
-- `routine-poll-result.made-progress` and the explicit `routine-id`-keyed polling protocol
-  likely go away — the host can just `await` each routine directly.
-
-That is a breaking ABI change, so it will require a major-version WIT bump. Any other-language
-SDK that ships a guest implementation should expect to regenerate bindings against the new
-world at that point.

samples/wasm-workflows/hello/Cargo.toml

@@ -4,7 +4,6 @@ version = "0.1.0"
 edition = "2024"
 
 [dependencies]
-temporalio-macros = { path = "../../../crates/macros" }
 temporalio-workflow = { path = "../../../crates/workflow" }
 
 [lib]