temporalio 0.1.1 → 0.3.0

data/bridge/Cargo.toml

@@ -1,29 +0,0 @@
-[package]
-name = "temporal-sdk-ruby-bridge"
-version = "0.1.1"
-authors = ["Anthony D <anthony@temporal.io>"]
-edition = "2021"
-repository = "https://github.com/temporalio/sdk-ruby"
-
-[dependencies]
-anyhow = "1.0"
-lazy_static = "1.4.0"
-parking_lot = { version = "0.12", features = ["send_guard"] }
-prost = "0.11"
-rutie = { version = "0.8.4", features = ["no-link"] }
-temporal-client = { version = "0.1.0", path = "./sdk-core/client" }
-temporal-sdk-core = { version = "0.1.0", path = "./sdk-core/core" }
-temporal-sdk-core-api = { version = "0.1.0", path = "./sdk-core/core-api" }
-temporal-sdk-core-protos = { version = "0.1.0", path = "./sdk-core/sdk-core-protos" }
-thiserror = "1.0.31"
-tokio = "1.23"
-tokio-util = "0.7.4"
-tonic = "0.8"
-url = "2.2"
-
-[lib]
-name = "temporal_sdk_ruby_bridge"
-crate-type = ["dylib"]
-
-[package.metadata.thermite]
-github_releases = true

data/bridge/sdk-core/ARCHITECTURE.md

@@ -1,76 +0,0 @@
-Core SDK Architecture
-===
-
-## High level description
-
-The below diagram depicts how future SDKs are split into two parts. The `sdk-core` common code, which is written in Rust, and a `sdk-lang` package specific to the language the user is writing their workflow/activity in. For example a user writing workflows in Rust would be pulling in (at least) two crates - `temporal-sdk-core` and `temporal-sdk-rust`.
-
-![Arch Diagram](https://lucid.app/publicSegments/view/7872bb33-d2b9-4b90-8aa1-bac111136aa5/image.png)
-
-The `core` communicates with the Temporal service in the same way that existing SDKs today do, via gRPC. It's responsible for polling for tasks, processing those tasks according to our state machine logic, and then driving the language-specific code and shuttling events to it and commands back.
-
-The `sdk-lang` side communicates with `sdk-core` via either C bindings, IPC, or (later) bindings to a WASM interface. Many languages already have nice support for calling into Rust code - generally speaking these implementations are using C bindings under the hood. For example, we use [neon](https://neon-bindings.com/) to support the TS/JS sdk, and we will likely use [PyO3](https://github.com/PyO3/pyo3) for Python. It is expected that such usages will layer another crate on top of `core` which brings in these language specific libraries to expose `core` to that language in an ergonomic manner. IPC will exist as a thin layer on top of the C bindings. Care should be taken here to avoid unnecessary copying and [de]serialization. Then `sdk-lang` is responsible for dispatching tasks to the appropriate user code (to whatever extent parts of this can be reasonably put in the core code, we desire that to make lang-specific SDKs as small as possible).
-
-As a general note, the more we can push from `sdk-lang` into `sdk-core`, the easier our ecosystem is to maintain in the long run as we will have less semantically identical code.
-
-### Glossary of terms
-
-There are many concepts involved in the chain of communication from server->core->lang that all roughly mean "Do something". Unfortunately this leads to quite a lot of overloaded terminology in the code. This list should help to disambiguate:
-
-* `HistoryEvent` (often referred to simply as an `Event`): These events come from the server and represent the history of the workflow. They are defined in the protobuf definitions for the Temporal service itself.
-* `Command`: These are the commands defined in the temporal service protobufs that are returned by clients upon completing a `WorkflowTask`. For example, starting a timer or an activity.
-* `WorkflowTask`: These are how the server represents the need to run user workflow code (or the result of it executing). See the `HistoryEvent` proto definition for more.
-* `WorkflowActivation`: These are produced by the Core SDK when the lang sdk needs to "activate" the user's workflow code, either running it from the beginning or resuming a cached workflow.
-* `WorkflowActivationJob` (shorthand: `Job`s): These are included in `WorkflowActivation`s and represent the actual things that have happened since the last time the workflow was activated (if ever). EX: Firing a timer, proceeding with the result of an activity, etc. They are typically derived from `HistoryEvent`s, but also include things like evicting a run from the cache.
-* `WorkflowActivationCompletion`: Provided by the lang side when completing an activation. The (successful) completion contains one or more `WorkflowCommand`s, which are often translated into `Command`s as defined in the Temporal service protobufs, but also include things like query responses.
-
-Additional clarifications that are internal to Core:
-* `StateMachine`s also handle events and produce commands, which often map directly to the above `HistoryEvent`s and `Command`s, but are distinct types. The state machine library is Temporal agnostic - but all interactions with the machines pass through a `TemporalStateMachine` trait, which accepts `HistoryEvent`s, and produces `WorkflowTrigger`s.
-* `WorkflowTrigger`: These allow the state machines to trigger things to happen to the workflow. Including pushing new `WfActivationJob`s, or otherwise advancing workflow state.
-
-
-### Core SDK Responsibilities
-
-- Communication with Temporal service using a generated gRPC client, which is wrapped with somewhat more ergonomic traits.
-- Provide interface for language-specific SDK to drive event loop and handle returned commands. The lang sdk will continuously call/poll the core SDK to receive new tasks, which either represent workflows being started or awoken (`WorkflowActivation`) or activities to execute (`ActivityTask`). It will then call its workflow/activity functions with the provided information as appropriate, and will then push completed tasks back into the core SDK.
-- Advance state machines and report back to the temporal server as appropriate when handling events and commands
-
-### Language Specific SDK Responsibilities
-
-- Periodically poll Core SDK for tasks
-- Call workflow and activity functions as appropriate, using information in events it received from Core SDK
-- Return results of workflows/activities to Core SDK
-- Manage concurrency using language appropriate primitives. For example, it is up to the language side to decide how frequently to poll, and whether or not to execute worklows and activities in separate threads or coroutines, etc.
-
-### Example Sequence Diagrams
-
-Here we consider what the sequence of API calls would look like for a simple workflow executing a happy path. The hello-world workflow & activity in imaginary Rust (don't pay too much attention to the specifics, just an example) is below. It is meant to be like our most basic hello world samples.
-
-```rust
-#[workflow]
-async fn hello_world_workflow(name: &str) -> Result<String, Error> {
-    info!("Hello world workflow started! Name: {}", name);
-    // Very much TBD how this would actually work in rust sdk. Many options here.
-    activity!(hello_activity(name), timeout: 2s).await
-}
-
-#[activity]
-async fn hello_activity(name: &str) -> String {
-    format!("Hello {}!", name)
-}
-```
-
-[![](https://mermaid.ink/img/pako:eNptk81O6zAQhV9l5AWr8gIRqoQCC0QXQJDuJpvBnrZWbY-vf9rbi3h3bJqE0JKVlfP5zMyx_S4kKxKNiPQ3k5N0p3ET0PYOyucxJC21R5egA4zwStZzQAMdhb2WdIm1FWs5EHR3j5fyqsordJuTfAJWcL1cQtvAg9NJo9H_CQ4cdhTmetfAJnjZQJeK4Z-irw0f7v-RzEmzG80Ms__aXVVIGHfgA0uKUbvNCWl_-j2xMaPda-GfM-Vhsg6uh9aqEOEKtjomDseizb0KcOu9OU5yYogJE4FFudWO4ometUh7KnnU5VkItR1YcwCUSe-xzhanWpVZNTC2ezshc5MCvGQ3hbCoAahcIgDJ1qJTcaKHmpd-LVtvqK5u3sJSskuoXUnwzOJ7fLXHcn1-nZqcGk_nLPoXip6dmqc_FCZ1sXdKqNvmpPhQfouFsBQsalWu8HvFepG2ZKkXTVkqDLte9O6jcNmr0tm90uV8RLNGE2khMCfujk6KJoVMIzS8gYH6-ASOZQf0)](https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNptk81O6zAQhV9l5AWr8gIRqoQCC0QXQJDuJpvBnrZWbY-vf9rbi3h3bJqE0JKVlfP5zMyx_S4kKxKNiPQ3k5N0p3ET0PYOyucxJC21R5egA4zwStZzQAMdhb2WdIm1FWs5EHR3j5fyqsordJuTfAJWcL1cQtvAg9NJo9H_CQ4cdhTmetfAJnjZQJeK4Z-irw0f7v-RzEmzG80Ms__aXVVIGHfgA0uKUbvNCWl_-j2xMaPda-GfM-Vhsg6uh9aqEOEKtjomDseizb0KcOu9OU5yYogJE4FFudWO4ometUh7KnnU5VkItR1YcwCUSe-xzhanWpVZNTC2ezshc5MCvGQ3hbCoAahcIgDJ1qJTcaKHmpd-LVtvqK5u3sJSskuoXUnwzOJ7fLXHcn1-nZqcGk_nLPoXip6dmqc_FCZ1sXdKqNvmpPhQfouFsBQsalWu8HvFepG2ZKkXTVkqDLte9O6jcNmr0tm90uV8RLNGE2khMCfujk6KJoVMIzS8gYH6-ASOZQf0)
-
-## API Definition
-
-We define the interface between the core and lang SDKs in terms of gRPC service definitions. The actual implementations of this "service" are not generated by gRPC generators, but the messages themselves are, and make it easier to hit the ground running in new languages.
-
-See the latest API definition [here](https://github.com/temporalio/sdk-core/tree/master/protos/local/temporal/sdk/core)
-
-
-## Other topics
-- [Sticky task queues](arch_docs/sticky_queues.md)
-
-## Workflow Processing Internals
-![Workflow Internals](arch_docs/diagrams/workflow_internals.svg)

data/bridge/sdk-core/Cargo.toml

@@ -1,2 +0,0 @@
-[workspace]
-members = ["core", "client", "core-api", "fsm", "test-utils", "sdk-core-protos", "sdk"]

data/bridge/sdk-core/LICENSE.txt

@@ -1,23 +0,0 @@
-Temporal Core SDK
-
-The MIT License
-
-Copyright (c) 2021 Temporal Technologies, Inc. All Rights Reserved
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

data/bridge/sdk-core/README.md

@@ -1,117 +0,0 @@
-[![Build status](https://badge.buildkite.com/c23f47f4a827f04daece909963bd3a248496f0cdbabfbecee4.svg?branch=master)](https://buildkite.com/temporal/core-sdk?branch=master)
-
-Core SDK that can be used as a base for other Temporal SDKs. It is currently used as the base of:
-
-- [TypeScript SDK](https://github.com/temporalio/sdk-typescript/)
-- [Python SDK](https://github.com/temporalio/sdk-python/)
-- [.NET SDK](https://github.com/temporalio/sdk-dotnet/)
-- [Ruby SDK](https://github.com/temporalio/sdk-ruby/)
-
-For the reasoning behind the Core SDK, see: 
-
-- [Why Rust powers Temporal’s new Core SDK](https://temporal.io/blog/why-rust-powers-core-sdk).
-
-See the [Architecture](ARCHITECTURE.md) doc for some high-level information about how Core works
-and how language layers interact with it.
-
-# Development
-
-You will need the `protoc` protobuf compiler 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 `./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.
-
-Visualized (dev dependencies are in blue):
-
-![Crate dependency graph](./etc/deps.svg)
-
-All the following commands are enforced for each pull request:
-
-## Building and testing
-
-You can buld and test the project using cargo:
-`cargo build`
-`cargo test`
-
-Run integ tests with `cargo integ-test`. You will need to already be running the server:
-`docker-compose -f .buildkite/docker/docker-compose.yaml up`
-
-## Formatting
-To format all code run:
-`cargo fmt --all`
-
-## Linting
-We are using [clippy](https://github.com/rust-lang/rust-clippy) for linting.
-You can run it using:
-`cargo clippy --all -- -D warnings`
-
-## Debugging
-The crate uses [tracing](https://github.com/tokio-rs/tracing) to help with debugging. To enable
-it for a test, insert the below snippet at the start of the test. By default, tracing data is output
-to stdout in a (reasonably) pretty manner.
-
-```rust
-crate::telemetry::test_telem_console();
-```
-
-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:
-
-`docker-compose -f .buildkite/docker/docker-compose.yaml -f .buildkite/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.
-
-## Proto files
-
-This repo uses a subtree for upstream protobuf files. The path `protos/api_upstream` is a
-subtree. To update it, use:
-
-`git pull --squash -s subtree ssh://git@github.com/temporalio/api.git master --allow-unrelated-histories`
-
-Do not question why this git command is the way it is. It is not our place to interpret git's ways.
-
-The java testserver protos are also pulled from the sdk-java repo, but since we only need a
-subdirectory of that repo, we just copy the files with read-tree:
-```bash
-# add sdk-java as a remote if you have not already
-git remote add -f -t master --no-tags testsrv-protos git@github.com:temporalio/sdk-java.git
-# delete existing protos
-git rm -rf protos/testsrv_upstream
-# pull from upstream & commit
-git read-tree --prefix protos/testsrv_upstream -u testsrv-protos/master:temporal-test-server/src/main/proto
-git commit
-```
-
-## Fetching Histories
-Tests which would like to replay stored histories rely on that history being made available in
-binary format. You can fetch histories in that format like so (from a local docker server):
-
-`cargo run --bin histfetch {workflow_id} [{run_id}]`
-
-You can change the `TEMPORAL_SERVICE_ADDRESS` env var to fetch from a different address.
-
-## Style Guidelines
-
-### Error handling
-Any error which is returned from a public interface should be well-typed, and we use 
-[thiserror](https://github.com/dtolnay/thiserror) for that purpose.
-
-Errors returned from things only used in testing are free to use 
-[anyhow](https://github.com/dtolnay/anyhow) for less verbosity.
-
-
-# The Rust "SDK"
-This repo contains a *prototype* Rust sdk in the `sdk/` directory. This SDK should be considered
-pre-alpha in terms of its API surface. Since it's still using Core underneath, it is generally
-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.

data/bridge/sdk-core/arch_docs/diagrams/README.md

@@ -1,10 +0,0 @@
-This directory contains diagrams used in the arch documents.
-
-They can be embedded into those documents two ways:
-
-* by the technique described here using the plantuml proxy service:
-  https://stackoverflow.com/questions/32203610/how-to-integrate-uml-diagrams-into-gitlab-or-github
-* By pasting them into https://www.planttext.com/ and then embedding the resulting SVG link
-
-The first technique has the problem that the PR won't show changes, since it's always from master.
-The second has the problem that you have to update it by hand. Pick your poison.

data/bridge/sdk-core/arch_docs/diagrams/sticky_queues.puml

@@ -1,40 +0,0 @@
-@startuml
-
-title "Sticky Task Queue Interactions"
-
-participant "Worker 1" as w1
-participant "Server" as fe
-queue "some_tq" as gq
-queue "some_tq_worker_1_xxx" as sq
-
-w1 -> fe : Poll on ""some_tq""
-fe <- gq : grab next task
-fe --> w1 : Workflow Task (entire history)
-
-w1 -> w1 : Process task
-w1 -> fe : Task complete, use task queue ""some_tq_worker_1_xxx""
-
-fe -> fe : An event, like a timer firing
-fe -> sq ** : Enqueue task
-
-loop Processing workflow tasks on a specific queue
-w1 -> fe : Poll on ""some_tq_worker_1_xxx""
-fe <- sq : grab next task
-fe --> w1 : Workflow Task (only new events)
-w1 -> w1 : Process task
-w1 -> fe : Task complete, use task queue ""some_tq_worker_1_xxx""
-fe -> fe : An event, like a timer firing
-fe -> sq : Enqueue task
-end
-
-w1 -> w1 : Evict workflow from cache
-note right : Eviction happens of this workflow for some reason
-
-w1 -> fe : ResetSticky (includes which workflow execution)
-
-fe -> fe : An event, like a timer firing
-fe -> gq : Enqueue task
-note left : We go back to the shared queue
-
-
-@enduml