@temporalio/core-bridge 1.13.1 → 1.14.0

package/sdk-core/README.md

@@ -26,18 +26,16 @@ installed to build Core.
 
 This repo is composed of multiple crates:
 
-- temporal-sdk-core-protos `./sdk-core-protos` - Holds the generated proto code and extensions.
-- temporal-client `./client` - Defines client(s) for interacting with the Temporal gRPC service.
-- temporal-sdk-core-api `./core-api` - Defines the API surface exposed by Core.
-- temporal-sdk-core `./core` - The Core implementation.
-- temporal-sdk-core-c-bridge `./core-c-bridge` - Provides C bindings for Core.
-- temporal-sdk `./sdk` - A (currently prototype) Rust SDK built on top of Core. Used for testing.
-- rustfsm `./fsm` - Implements a procedural macro used by core for defining state machines
-  (contains subcrates). It is Temporal-agnostic.
+- temporalio-client `./crates/client` - Defines client(s) for interacting with the Temporal gRPC service.
+- temporalio-common `./crates/common` - Common code & protobuf definitions
+- temporalio-sdk-core `./crates/core` - The Core implementation.
+- temporalio-sdk-core-c-bridge `./crates/core-c-bridge` - Provides C bindings for Core.
+- temporalio-macros `./crates/macros` - Implements procedural macros used by core and the SDK.
+- temporalio-sdk `./crates/sdk` - A (currently prototype) Rust SDK built on top of Core. Used for testing.
 
 Visualized (dev dependencies are in blue):
 
-![Crate dependency graph](./etc/deps.svg)
+![Crate dependency graph](./arch_docs/diagrams/deps.svg)
 
 All the following commands are enforced for each pull request:
 
@@ -52,6 +50,10 @@ use an already-running server by passing `-s external`.
 
 Run load tests with `cargo test --test heavy_tests`.
 
+NOTE: Integration tests should pass locally, if running on MacOS and you see integration tests consistently failing
+with an error that mentions `Too many open files`, this is likely due to `ulimit -n` being too low. You can raise
+it temporarily (current shell) with `ulimit -n 65535`, or add it to your `~/.zshrc` file to apply to all shells.
+
 ## Formatting
 
 To format all code run:
@@ -60,8 +62,8 @@ To format all code run:
 ## Linting
 
 We are using [clippy](https://github.com/rust-lang/rust-clippy) for linting.
-You can run it using:
-`cargo clippy --all -- -D warnings`
+We have a couple aliases for linting that make sure various targets are hit:
+`cargo lint` and `cargo test-lint`.
 
 ## Debugging
 
@@ -75,10 +77,10 @@ crate::telemetry::telemetry_init_fallback();
 
 The passed in options to initialization can be customized to export to an OTel collector, etc.
 
-To run integ tests with OTel collection on, you can use `integ-with-otel.sh`. You will want to make
-sure you are running the collector via docker, which can be done like so:
+To run integ tests with OTel collection on, you can use `etc/integ-with-otel.sh`. You will want to
+make sure you are running the collector via docker, which can be done like so:
 
-`docker-compose -f docker/docker-compose.yaml -f docker/docker-compose-telem.yaml up`
+`docker-compose -f etc/docker/docker-compose.yaml -f etc/docker/docker-compose-telem.yaml up`
 
 If you are working on a language SDK, you are expected to initialize tracing early in your `main`
 equivalent.
@@ -133,4 +135,3 @@ pre-alpha in terms of its API surface. Since it's still using Core underneath, i
 functional. We do not currently have any firm plans to productionize this SDK. If you want to write
 workflows and activities in Rust, feel free to use it - but be aware that the API may change at any
 time without warning and we do not provide any support guarantees.
-

package/sdk-core/arch_docs/diagrams/TimerMachine_Coverage.puml

@@ -0,0 +1,14 @@
+@startuml
+[*] --> Created
+Created -[#blue]-> StartCommandCreated: Schedule
+StartCommandCreated -[#blue]-> StartCommandCreated: CommandStartTimer
+StartCommandCreated -[#blue]-> StartCommandRecorded: TimerStarted
+StartCommandCreated -[#blue]-> Canceled: Cancel
+StartCommandRecorded -[#blue]-> Fired: TimerFired
+StartCommandRecorded -[#blue]-> CancelTimerCommandCreated: Cancel
+CancelTimerCommandCreated --> CancelTimerCommandCreated: Cancel
+CancelTimerCommandCreated -[#blue]-> CancelTimerCommandSent: CommandCancelTimer
+CancelTimerCommandSent --> Canceled: TimerCanceled
+Canceled -[#blue]-> Canceled: Cancel
+Fired -[#blue]-> Fired: Cancel
+@enduml

package/sdk-core/arch_docs/diagrams/deps.svg

@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 14.0.1 (0)
+ -->
+<!-- Pages: 1 -->
+<svg width="274pt" height="332pt"
+ viewBox="0.00 0.00 274.00 332.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 328)">
+<polygon fill="white" stroke="none" points="-4,4 -4,-328 270,-328 270,4 -4,4"/>
+<!-- 0 -->
+<g id="node1" class="node">
+<title>0</title>
+<polygon fill="none" stroke="black" points="126.25,-252 0,-252 0,-216 126.25,-216 126.25,-252"/>
+<text xml:space="preserve" text-anchor="middle" x="63.12" y="-228.95" font-family="Times,serif" font-size="14.00">temporalio&#45;sdk&#45;core</text>
+</g>
+<!-- 1 -->
+<g id="node2" class="node">
+<title>1</title>
+<polygon fill="none" stroke="black" points="191,-108 81.25,-108 81.25,-72 191,-72 191,-108"/>
+<text xml:space="preserve" text-anchor="middle" x="136.12" y="-84.95" font-family="Times,serif" font-size="14.00">temporalio&#45;client</text>
+</g>
+<!-- 0&#45;&gt;1 -->
+<g id="edge1" class="edge">
+<title>0&#45;&gt;1</title>
+<path fill="none" stroke="black" d="M88.81,-215.72C100.5,-206.5 113.43,-194.14 121.12,-180 131.16,-161.58 134.8,-138.08 135.99,-119.85"/>
+<polygon fill="black" stroke="black" points="139.48,-120.13 136.4,-109.99 132.49,-119.83 139.48,-120.13"/>
+</g>
+<!-- 2 -->
+<g id="node3" class="node">
+<title>2</title>
+<polygon fill="none" stroke="black" points="158.38,-36 29.88,-36 29.88,0 158.38,0 158.38,-36"/>
+<text xml:space="preserve" text-anchor="middle" x="94.12" y="-12.95" font-family="Times,serif" font-size="14.00">temporalio&#45;common</text>
+</g>
+<!-- 0&#45;&gt;2 -->
+<g id="edge2" class="edge">
+<title>0&#45;&gt;2</title>
+<path fill="none" stroke="black" d="M35.48,-215.54C23.8,-206.51 11.45,-194.35 5.12,-180 -1.33,-165.36 0.25,-159.24 5.12,-144 17.5,-105.3 46.72,-68.34 68.32,-44.79"/>
+<polygon fill="black" stroke="black" points="70.83,-47.23 75.14,-37.55 65.73,-42.43 70.83,-47.23"/>
+</g>
+<!-- 3 -->
+<g id="node4" class="node">
+<title>3</title>
+<polygon fill="none" stroke="black" points="112.38,-180 13.88,-180 13.88,-144 112.38,-144 112.38,-180"/>
+<text xml:space="preserve" text-anchor="middle" x="63.12" y="-156.95" font-family="Times,serif" font-size="14.00">temporalio&#45;sdk</text>
+</g>
+<!-- 0&#45;&gt;3 -->
+<g id="edge3" class="edge">
+<title>0&#45;&gt;3</title>
+<path fill="none" stroke="blue" d="M57.21,-215.7C56.46,-208.41 56.21,-199.73 56.48,-191.54"/>
+<polygon fill="blue" stroke="blue" points="59.97,-191.82 57.13,-181.61 52.98,-191.36 59.97,-191.82"/>
+</g>
+<!-- 1&#45;&gt;2 -->
+<g id="edge4" class="edge">
+<title>1&#45;&gt;2</title>
+<path fill="none" stroke="black" d="M125.74,-71.7C121.06,-63.9 115.43,-54.51 110.22,-45.83"/>
+<polygon fill="black" stroke="black" points="113.31,-44.18 105.17,-37.4 107.31,-47.78 113.31,-44.18"/>
+</g>
+<!-- 3&#45;&gt;0 -->
+<g id="edge7" class="edge">
+<title>3&#45;&gt;0</title>
+<path fill="none" stroke="black" d="M69.02,-180.1C69.78,-187.37 70.03,-196.04 69.78,-204.24"/>
+<polygon fill="black" stroke="black" points="66.29,-203.98 69.14,-214.19 73.27,-204.43 66.29,-203.98"/>
+</g>
+<!-- 3&#45;&gt;1 -->
+<g id="edge5" class="edge">
+<title>3&#45;&gt;1</title>
+<path fill="none" stroke="black" d="M81.17,-143.7C89.86,-135.37 100.44,-125.22 109.98,-116.07"/>
+<polygon fill="black" stroke="black" points="112.15,-118.84 116.94,-109.39 107.3,-113.79 112.15,-118.84"/>
+</g>
+<!-- 3&#45;&gt;2 -->
+<g id="edge6" class="edge">
+<title>3&#45;&gt;2</title>
+<path fill="none" stroke="black" d="M63.38,-143.68C64,-125.56 65.97,-96.39 72.12,-72 74.27,-63.5 77.54,-54.58 80.91,-46.53"/>
+<polygon fill="black" stroke="black" points="84.01,-48.17 84.85,-37.61 77.61,-45.34 84.01,-48.17"/>
+</g>
+<!-- 4 -->
+<g id="node5" class="node">
+<title>4</title>
+<polygon fill="none" stroke="black" points="266,-324 90.25,-324 90.25,-288 266,-288 266,-324"/>
+<text xml:space="preserve" text-anchor="middle" x="178.12" y="-300.95" font-family="Times,serif" font-size="14.00">temporalio&#45;sdk&#45;core&#45;c&#45;bridge</text>
+</g>
+<!-- 4&#45;&gt;0 -->
+<g id="edge10" class="edge">
+<title>4&#45;&gt;0</title>
+<path fill="none" stroke="black" d="M149.4,-287.52C134.75,-278.6 116.73,-267.63 100.96,-258.03"/>
+<polygon fill="black" stroke="black" points="103.14,-255.26 92.77,-253.05 99.5,-261.24 103.14,-255.26"/>
+</g>
+<!-- 4&#45;&gt;1 -->
+<g id="edge8" class="edge">
+<title>4&#45;&gt;1</title>
+<path fill="none" stroke="black" d="M174.76,-287.85C167.54,-251.07 150.51,-164.29 141.67,-119.24"/>
+<polygon fill="black" stroke="black" points="145.16,-118.86 139.8,-109.72 138.29,-120.2 145.16,-118.86"/>
+</g>
+<!-- 4&#45;&gt;2 -->
+<g id="edge9" class="edge">
+<title>4&#45;&gt;2</title>
+<path fill="none" stroke="black" d="M186.41,-287.59C204.63,-246.52 243.27,-141.82 200.12,-72 192.07,-58.97 179.74,-49.04 166.3,-41.5"/>
+<polygon fill="black" stroke="black" points="168.21,-38.55 157.71,-37.12 165.03,-44.78 168.21,-38.55"/>
+</g>
+</g>
+</svg>

package/sdk-core/arch_docs/sdks_intro.md

@@ -0,0 +1,299 @@
+# Intro to Temporal SDKs
+
+This document is primarily meant as an onboarding guide for new Temporal SDK developers, to be
+accompanied by a live presentation. Hence, content does not have maximal context. If reading this
+independently, you will also want to refer to our documentation [site](https://docs.temporal.io).
+
+## Primary SDK Concepts
+
+See also our
+[official docs on basic concepts](https://docs.temporal.io/evaluate/understanding-temporal).
+
+### Workflows
+
+Workflows are durable programs. Their state is materialized from event history and they can be
+replayed zero or more times. Workflow code must be deterministic and must use SDK Workflow-specific
+APIs. Side effects and non-deterministic APIs should be placed in Activities.
+
+**Example Workflow Code (Python):**
+
+```python
+from datetime import timedelta
+from temporalio import workflow
+
+@workflow.defn
+class SayHello:
+    @workflow.run
+    async def run(self, name: str) -> str:
+        return await workflow.execute_activity(
+            say_hello, name, schedule_to_close_timeout=timedelta(seconds=5)
+        )
+```
+
+### Activities
+
+Activities are invoked from a Workflow and can run arbitrary code. They can be retried, are subject
+to timeouts, and should be idempotent/reentrant. Activities can be short or long-running and can
+heartbeat.
+
+**Example Activity Code (Python):**
+
+```python
+from temporalio import activity
+
+@activity.defn
+async def say_hello(name: str) -> str:
+    return f"Hello, {name}!"
+```
+
+### Clients
+
+Clients serve as a driver for interaction with the Temporal server. They provide a high-level API
+for a subset of gRPC calls, including Workflow "CRUD" operations, Activity completion, and
+Schedules.
+
+**Example Client Code (Python):**
+
+``` python
+from temporalio.client import Client
+
+# Import the workflow from the previous code
+from .workflows import SayHello
+
+async def main():
+    client = await Client.connect("localhost:7233")
+
+    result = await client.execute_workflow(
+        SayHello.run, "my name", id="my-workflow-id", task_queue="my-task-queue")
+
+    print(f"Result: {result}")
+```
+
+### Workers
+
+Workers are stateless entities that poll the server for Workflow, Activity, and Nexus tasks. They
+run user-defined Workflows, Activities, and Nexus Operations, manage concurrency and rate limits,
+and provide the language runtime for workflows.
+
+**Example Worker Code (Python):**
+
+``` python
+from temporalio.client import Client
+from temporalio.worker import Worker
+
+from .activities import say_hello
+from .workflows import SayHello
+
+async def main():
+    client = await Client.connect("localhost:7233")
+
+    worker = Worker(
+        client,
+        task_queue="my-task-queue",
+        workflows=[SayHello],
+        activities=[say_hello])
+    await worker.run()
+```
+
+## SDK \<-\> Server Interaction
+
+### Event History and it's construction
+
+Event history is a record of all events that have occurred in a Workflow. Workflow tasks are the
+fundamental unit of progress for Workflows. Any time your Workflow code makes progress, it does so
+because your worker processed one of these Workflow tasks. Workflow tasks contain some or all of the
+Workflow’s history, along with possibly queries and other bits of information the worker might care
+about.
+
+The first few events in a workflow's history always look like this:
+
+![initial_event_history.png](diagrams/initial_event_history.png)
+
+The first Workflow task for a Workflow always includes the initial events. When the SDK receives a
+task, it processes the history, runs your Workflow code, and eventually responds with commands to
+the server. Commands are actions like "start a timer" or "run an Activity."
+
+A sequence diagram of this process is shown below. Not everything may make sense yet, but we can
+refer back to this diagram during later explanations.
+
+```mermaid
+%%{ init : { "theme" : "default", "themeVariables" : { "background" : "#fff" }}}%%
+sequenceDiagram
+    box rgb(255, 255, 255)
+      participant Client
+      participant Server
+      participant SDK
+      participant UserCode as "User Code"
+    end
+
+    Client ->> Server: StartWorkflowExecution RPC
+    Server ->> Server: Generate Workflow Task & persist
+    Server -->> Client: runID
+
+    loop Workflow Task Polling
+        rect rgb(200, 230, 200)
+            SDK ->> Server: PollWorkflowTaskQueueRequest
+            opt Something triggers new Workflow Task
+                Server ->> Server: Generate Workflow Task & persist
+            end
+            Server -->> SDK: PollWorkflowTaskQueueResponse
+        end
+
+        rect rgb(220, 200, 220)
+            loop Processing one Workflow Task
+                SDK ->> SDK: Apply workflow history to state
+                SDK ->> UserCode: Activate & Unblock Awaitables
+                UserCode -->> SDK: Blocked on some awaitable or complete
+            end
+
+            SDK ->> Server: RespondWorkflowTaskCompletedRequest
+            Server ->> Server: Persist & possibly reply with new Workflow Task
+            Server -->> SDK: RespondWorkflowTaskCompletedResponse
+        end
+    end
+```
+
+**How History is Constructed:**
+
+Workflow tasks contain history and are responded to with commands. Every command is turned into a
+corresponding event (referred to as "dual" or "command-events"). The Temporal server takes action on
+received commands, and the consequences of those actions also become events (e.g., `TimerFired`,
+`ActivityTaskCompleted`). When events that trigger a new Workflow task occur, the Temporal server
+generates a new Workflow task because a worker needs to run the Workflow code to process this new
+information.
+
+This cycle continues until the Workflow is complete: new Workflow Tasks are created, processed by
+the SDK, responded to with commands, until a new Workflow task begins, and so on.
+
+We will use the following example Workflow to illustrate this process:
+
+```python
+@activity.defn
+async def say_hello(name: str) -> str:
+    return f"Hello, {name}!"
+
+@workflow.defn
+class ReplayExampleWorkflow:
+    @workflow.run
+    async def run(self, name: str) -> str:
+        my_hello = workflow.execute_activity(
+            say_hello, name, schedule_to_close_timeout=timedelta(seconds=5)
+        )
+        timer = workflow.sleep(10)
+        (activity_result, _) = await asyncio.gather(my_hello, timer)
+        return activity_result
+```
+
+**Example Workflow History Analysis:**
+
+1. The initial Workflow task is processed. The `execute_activity` call creates a command for
+   scheduling an Activity, and `workflow.sleep` creates a command for a timer.
+2. The `asyncio.gather` line indicates a wait for both the activity and timer to resolve.
+3. The SDK knows when to respond to the task because the Workflow cannot make any more progress. All
+   buffered commands are sent to the server (activity and timer commands, in that order). This
+   completes the first Workflow task.
+4. The server receives these commands, which are converted into `ActivityTaskScheduled` and
+   `TimerStarted` events (duals of the commands).
+5. When the Activity completes, an `ActivityTaskCompleted` event is added to the history. This
+   triggers a new Workflow task.
+6. The worker processes this new task, and the future `my_hello` is resolved. The Workflow code,
+   however, is still blocked on `gather` because the timer hasn't fired. The SDK replies with an
+   empty list of commands, indicating no new actions.
+7. The timer fires, resulting in a `TimerFired` event. This generates another Workflow task.
+8. When this task is processed, the `gather` call resolves. The Workflow function returns, producing
+   a `CompleteWorkflowExecution` command.
+9. This command is converted into a `WorkflowExecutionCompleted` event, and the Workflow finishes.
+
+The complete history at the end of all this is the following:
+
+1. Workflow Execution Started
+2. Workflow Task Scheduled
+3. Workflow Task Started
+4. Workflow Task Completed
+5. Activity Task Scheduled `say_hello`
+6. Timer Started `1 (1s)`
+7. Activity Task Started `say_hello`
+8. Activity Task Completed `say_hello`
+9. Workflow Task Scheduled
+10. Workflow Task Started
+11. Workflow Task Completed `Notice: No commands sent`
+12. Timer Fired `1 (1s)`
+13. Workflow Task Scheduled
+14. Workflow Task Started
+15. Workflow Task Completed
+16. Workflow Execution Completed
+
+This repetitive nature of processing Workflow tasks, where the SDK polls for tasks, processes
+history, unblocks user code, and sends new commands, continues until Workflow completion.
+
+### How Replay Works
+
+Above we described the sequence of events as if the Python objects remained in memory between
+workflow tasks, with asyncio futures "waiting" to be resolved. That is indeed typically the case,
+but technically it's a performance optimization (we refer to it as the "sticky" optimization), where
+history is delivered in incremental pieces rather than in its entirety. When a worker doesn't have
+the workflow already in-cache, it "replays" the workflow code from the beginning (this is why we
+said workers are stateless), making use of the supplied history to deterministically reach precisely
+the state it had reached previously.
+
+Replay is fundamental to Temporal's durability and determinism, and so we'll now look at it in a bit
+more detail.
+
+**History Processing:**
+
+SDKs process events from history serially, one at a time. Each event is fed to a specific instance
+of a state machine. There is a type of state machine for every command, as well as some non-command
+events/concepts. The state of a particular Workflow run consists of the combination of the states of
+these state machines, and importantly, the order in which they are created.
+
+**Timer State Machine in Core (Example):**
+
+We can use the Timer state machine to illustrate how determinism is enforced:
+
+<img src="https://uml.planttext.com/plantuml/svg/fL912iCW4Bpx2g6tWX_eeGI4Fg3s5d8mkj206h3w_oOR8q9jfFJaBhCpiuvsho1zYDQG_ZnGngwKUv01D4adPVrfD1661HBhB9-jbKud-4A5UeAE1aW5RP9JZzXZik1_KRc3chrUPP2AqB9uGu5Bfy2WELQa9baIRfFF7bWt6Pim4Zukl7b-dTYUu1_-qHe2NCYX5t15Rnqjbia9x2tPYyDiCQzAc0dkmEdbxxq1" width="500" alt="Timer FSM Diagram"/>
+
+When we first create the timer, we immediately schedule it, which produces the `StartTimer` command,
+which becomes the `TimerStarted` event. The `Created` state isn’t really necessary here, but the
+schedule transition serves as a convenient way to produce the start timer command.
+
+When we see a `TimerStarted` event on history, we know that the command we issued exists in Workflow
+history, and we move to the StartCommandRecorded state and wait to see what happens - it can either
+fire or be canceled.
+
+In our example, there’s a `TimerFired` event, so when the SDK processes that event, we’d take that
+transition, and the machine ends up in the final fired state
+
+At this point, you might be wondering - why does that `StartCommandRecorded` state matter? Why have
+a transition for `TimerStarted` at all? We know we sent the command to the server, so why not just
+wait to see if the timer fires or is canceled from the `StartCommandCreated` state? The answer is
+that's a big part of the secret sauce for how we enforce determinism.
+
+**Enforcing Determinism:**
+
+A Workflow must always emit the same commands in the same sequence. Temporal can detect violations
+of this rule because of the "dual" events that each command produces. The `TimerStarted` transition
+ensures that when replaying a Workflow, the current code attempting to start a timer does so at the
+same point and in the same way as what exists in history. The order in which state machines are
+created by Workflow code also matters to ensure the same sequence of commands is produced. This
+prevents scenarios where changed code might run a command that should have been mutually exclusive
+with a command already in history.
+
+**Example of Nondeterminism:**
+
+If the order of arguments to `asyncio.gather` is swapped in the previous example Workflow, replaying
+the Workflow will result in a nondeterminism error (often referred to as an "NDE"):
+
+```
+temporalio.workflow.NondeterminismError: Workflow activation completion failed: Failure { failure:
+Some(Failure { message: "[TMPRL1100] Nondeterminism error: Timer machine does not handle this event:
+HistoryEvent(id: 5, ActivityTaskScheduled)", source: "", stack_trace: "", encoded_attributes: None,
+cause: None, failure_info: Some(ApplicationFailureInfo(ApplicationFailureInfo { r#type: "",
+non_retryable: false, details: None, next_retry_delay: None })) }), force_cause:
+NonDeterministicError }
+```
+
+This error occurs because the "dual" events in the history are not in the same order as the commands
+produced by the modified Workflow code. The timer machine, expecting a `TimerStarted` event,
+encounters an `ActivityTaskScheduled` event instead, leading to a nondeterminism error. In other
+words, we did not produce the same commands in the same order. This mechanism ensures Workflow state
+consistency.

package/sdk-core/{client → crates/client}/Cargo.toml

@@ -1,10 +1,10 @@
 [package]
-name = "temporal-client"
+name = "temporalio-client"
 version = "0.1.0"
 edition = "2024"
-authors = ["Spencer Judge <spencer@temporal.io>"]
+authors = ["Temporal Technologies Inc. <sdk@temporal.io>"]
 license-file = { workspace = true }
-description = "Clients for interacting with Temporal Clusters"
+description = "Clients for interacting with Temporal"
 homepage = "https://temporal.io/"
 repository = "https://github.com/temporalio/sdk-core"
 keywords = ["temporal", "workflow"]
@@ -18,36 +18,35 @@ anyhow = "1.0"
 async-trait = "0.1"
 backoff = "0.4"
 base64 = "0.22"
-derive_builder = { workspace = true }
+bon = "3"
 derive_more = { workspace = true }
+dyn-clone = "1.0"
 bytes = "1.10"
 futures-util = { version = "0.3", default-features = false }
 futures-retry = "0.6.0"
-http = "1.1"
+http = "1.3"
 http-body-util = "0.1"
-hyper = { version = "1.4.1" }
-hyper-util = "0.1.6"
+hyper = { version = "1.7.0" }
+hyper-util = "0.1.16"
 opentelemetry = { workspace = true, features = ["metrics"], optional = true }
 parking_lot = "0.12"
 slotmap = "1.0"
 thiserror = { workspace = true }
-tokio = "1.1"
+tokio = "1.47"
 tonic = { workspace = true, features = ["tls-ring", "tls-native-roots"] }
 tower = { version = "0.5", features = ["util"] }
 tracing = "0.1"
-url = "2.2"
-uuid = { version = "1.1", features = ["v4"] }
+url = "2.5"
+uuid = { version = "1.18", features = ["v4"] }
+rand = "0.9.2"
 
-[dependencies.temporal-sdk-core-protos]
-path = "../sdk-core-protos"
-
-[dependencies.temporal-sdk-core-api]
-path = "../core-api"
+[dependencies.temporalio-common]
+path = "../common"
 
 [dev-dependencies]
 assert_matches = "1"
 mockall = "0.13"
-rstest = "0.25"
+rstest = "0.26"
 
 [lints]
 workspace = true

package/sdk-core/{client → crates/client}/src/callback_based.rs

@@ -3,8 +3,7 @@
 
 use anyhow::anyhow;
 use bytes::{BufMut, BytesMut};
-use futures_util::future::BoxFuture;
-use futures_util::stream;
+use futures_util::{future::BoxFuture, stream};
 use http::{HeaderMap, Request, Response};
 use http_body_util::{BodyExt, StreamBody, combinators::BoxBody};
 use hyper::body::{Bytes, Frame};