From 2caf963f644ab7574a4ecd04262cb95e0353a205 Mon Sep 17 00:00:00 2001 From: starfleeth <128422269+starfleeth@users.noreply.github.com> Date: Tue, 1 Sep 2026 19:31:12 -0700 Subject: [PATCH 1/6] Refactor Lambda SDK references by language --- README.md | 9 +- SKILL.md | 30 +- references/aws-lambda/diagnostics.md | 22 +- references/aws-lambda/observability.md | 222 +----------- references/aws-lambda/sdk-go.md | 192 +++++++++++ references/aws-lambda/sdk-java.md | 318 ++++++++++++++++++ references/aws-lambda/sdk-python.md | 206 ++++++++++++ references/aws-lambda/sdk-typescript.md | 201 +++++++++++ references/aws-lambda/setup.md | 426 +----------------------- references/sdk-configuration.md | 331 ------------------ 10 files changed, 973 insertions(+), 984 deletions(-) create mode 100644 references/aws-lambda/sdk-go.md create mode 100644 references/aws-lambda/sdk-java.md create mode 100644 references/aws-lambda/sdk-python.md create mode 100644 references/aws-lambda/sdk-typescript.md delete mode 100644 references/sdk-configuration.md diff --git a/README.md b/README.md index 2821dc6..161302d 100644 --- a/README.md +++ b/README.md @@ -120,12 +120,15 @@ Nothing is created before you approve the resource list. Troubleshooting and ins |---|---| | [`SKILL.md`](SKILL.md) | Core workflow, safety gates, provider rules, and reference routing | | [`references/concepts.md`](references/concepts.md) | Architecture, invocation flow, autoscaling, lifecycle, constraints, and use cases | -| [`references/sdk-configuration.md`](references/sdk-configuration.md) | Go, Python, TypeScript, and Java packages, entry points, versioning behavior, and tuned defaults | -| [`references/aws-lambda/setup.md`](references/aws-lambda/setup.md) | End-to-end deployment, verification, and teardown workflow | +| [`references/aws-lambda/sdk-go.md`](references/aws-lambda/sdk-go.md) | Go package, API, handler, build, packaging, Lambda deployment values, tuned defaults, connection configuration, and OpenTelemetry integration | +| [`references/aws-lambda/sdk-python.md`](references/aws-lambda/sdk-python.md) | Python package, API, handler, build, packaging, Lambda deployment values, tuned defaults, connection configuration, OpenTelemetry integration, and diagnostics | +| [`references/aws-lambda/sdk-typescript.md`](references/aws-lambda/sdk-typescript.md) | TypeScript package, API, handler, Workflow pre-bundling, build, packaging, Lambda deployment values, tuned defaults, connection configuration, and OpenTelemetry integration | +| [`references/aws-lambda/sdk-java.md`](references/aws-lambda/sdk-java.md) | Java artifact, API, handler, callbacks, build, packaging, Lambda deployment values, tuned defaults, connection configuration, OpenTelemetry integration, logging, and diagnostics | +| [`references/aws-lambda/setup.md`](references/aws-lambda/setup.md) | Shared AWS and Temporal deployment lifecycle, verification, and teardown workflow | | [`references/aws-lambda/iam.md`](references/aws-lambda/iam.md) | Operator permissions, Lambda execution role, and Temporal invocation role | | [`references/aws-lambda/diagnostics.md`](references/aws-lambda/diagnostics.md) | Diagnostic decision tree and WCI inspection | | [`references/aws-lambda/versioning.md`](references/aws-lambda/versioning.md) | Immutable releases, updates, and rollback | -| [`references/aws-lambda/observability.md`](references/aws-lambda/observability.md) | OpenTelemetry and ADOT configuration | +| [`references/aws-lambda/observability.md`](references/aws-lambda/observability.md) | Shared ADOT Collector configuration, X-Ray enablement, and IAM permissions | | [`references/aws-lambda/self-hosted.md`](references/aws-lambda/self-hosted.md) | Self-hosted Temporal prerequisites and configuration | | [`assets/`](assets/) | CloudFormation templates for Temporal invocation roles | diff --git a/SKILL.md b/SKILL.md index 1cec203..3a1462d 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,7 +1,7 @@ --- name: temporal-serverless description: 'Deploy and operate Temporal Workers on serverless compute (AWS Lambda) driven by the Worker Controller Instance (WCI). Use when the user mentions: "serverless worker", "Temporal serverless", "Worker Controller Instance", "WCI", "deploy Temporal worker on Lambda", "Lambda packaging", "Lambda timeout", "WCI inspection", "CloudFormation Temporal".' -version: 0.6.0 +version: 0.6.1 --- # Skill: temporal-serverless @@ -19,7 +19,14 @@ This skill helps users deploy and operate Temporal Workers on serverless compute Only a provider marked Supported is covered. If a request names another, say it is not supported and stop; do not adapt a supported provider's material to it. **Never let the provider be an unstated assumption:** when the request does not name one, it is confirmed in the step 1 questions, not silently defaulted. -Every supported provider's directory carries the same layout — `setup.md`, `iam.md`, `versioning.md`, `diagnostics.md`, `observability.md`, `self-hosted.md`. Paths below are written `references//…`; substitute the directory from the table. Provider-specific commands, templates, permissions, and defaults live there — this file stays at the workflow level. When a step needs concrete commands, go to the reference file named at the end of that step. +Every supported provider's directory carries the same shared layout — `setup.md`, `iam.md`, `versioning.md`, `diagnostics.md`, `observability.md`, `self-hosted.md` — plus one `sdk-.md` file for each supported SDK. Paths below are written `references//…`; substitute the directory from the table. Provider-specific commands, templates, permissions, SDK APIs, and defaults live there — this file stays at the workflow level. When a step needs concrete commands or SDK details, go to the reference file named at the end of that step. + +| SDK language | AWS Lambda reference | +|---|---| +| Go | `references/aws-lambda/sdk-go.md` | +| Python | `references/aws-lambda/sdk-python.md` | +| TypeScript | `references/aws-lambda/sdk-typescript.md` | +| Java | `references/aws-lambda/sdk-java.md` | **Public Preview is not GA.** The APIs are still evolving and may change: pin SDK and CLI versions for anything long-lived, and read the installed package's actual API surface rather than writing from memory. @@ -132,9 +139,9 @@ Where the harness has a todo list, use it *in addition to* the printed checklist **Before the first account-mutating command, list what you are about to create — with final names — and get approval.** Name the target account and region, then every resource: compute unit, execution role, infrastructure stack, log group, deployment name, and Task Queue. Say plainly that they are live and billable. This is the mirror of the inventory in step 8, and it is worth more here than there: it makes the naming prefix concrete while changing it is still free, and the deployment name, build ID, and Task Queue become expensive to change once step 3 compiles them into the Worker. Skip it only when nothing will be created — a troubleshooting or inspection task. -3. **Author the Worker.** *Install the SDK's serverless Worker package before writing any code* — it is usually shipped separately from the main SDK — sometimes on its own version line, sometimes in lockstep with it, and in one SDK not separately at all — so having the base SDK installed does not mean it is importable. Then read the installed package's actual API surface and write against that; these are Public Preview APIs that drift between versions, and generating code from memory costs a build cycle. Entry-point names are not consistent between SDKs, so inspect first rather than pattern-matching from another language. Every Workflow must declare a versioning behavior (`Pinned` or `AutoUpgrade`), per-Workflow or as a Worker-level default — code without it fails at runtime. → `references/sdk-configuration.md` (package, install, entry point, tuned defaults) and `references//setup.md` (install commands, API-inspection recipes, handler shape). +3. **Author the Worker.** *Install the SDK's serverless Worker package before writing any code* — it is usually shipped separately from the main SDK — sometimes on its own version line, sometimes in lockstep with it, and in one SDK not separately at all — so having the base SDK installed does not mean it is importable. Then read the installed package's actual API surface and write against that; these are Public Preview APIs that drift between versions, and generating code from memory costs a build cycle. Entry-point names are not consistent between SDKs, so inspect first rather than pattern-matching from another language. Every Workflow must declare a versioning behavior (`Pinned` or `AutoUpgrade`), per-Workflow or as a Worker-level default — code without it fails at runtime. → `references//sdk-.md` (package, install, API inspection, entry point, handler shape, versioning behavior, tuned defaults). -4. **Package and deploy the compute unit.** Build and package per SDK, deploy the compute unit, and set the invocation deadline high enough for the Worker to start, connect, register the Task Queue, and shut down gracefully. Match the build's target architecture to the deployed compute unit's — a mismatch fails only at invocation time, not at build time. After a create or update, wait for the compute unit to reach a ready state before the next step; providers return from these calls while the unit is still settling. → `references//setup.md`. +4. **Package and deploy the compute unit.** Build and package per SDK, deploy the compute unit, and set the invocation deadline high enough for the Worker to start, connect, register the Task Queue, and shut down gracefully. Match the build's target architecture to the deployed compute unit's — a mismatch fails only at invocation time, not at build time. After a create or update, wait for the compute unit to reach a ready state before the next step; providers return from these calls while the unit is still settling. → `references//sdk-.md` (build, packaging, runtime, handler, architecture, and SDK-specific deployment values) and `references//setup.md` (shared deployment lifecycle). 5. **Grant Temporal permission to invoke the Worker.** Configure the compute provider's access so Temporal can invoke and inspect the Worker. This access is separate from the compute unit's own execution role — do not confuse the two. Two things to get right before you create anything: (a) this grant is **shared, account-wide infrastructure** that a previous deployment may already have created — look for an existing one and extend it to cover your new Worker rather than creating a parallel copy, and never delete or repurpose one you did not create without asking; (b) scope the grant so that *future* immutable builds are covered, not just today's — a grant pinned to one build breaks the next release in a way that surfaces later as an unrelated-looking invocation failure. → `references//iam.md`. @@ -183,7 +190,7 @@ Surface these early — they apply regardless of compute provider: - **Deployment name and build ID must match exactly** between the Worker code and the Worker Deployment Version. A mismatch causes an invocation loop (Temporal invokes → Worker polls with the wrong version → Task not processed → invoke again). Signature: rapid repeated invocations with no Workflow progress. - **Set the invocation deadline high enough.** Providers often default to a very short timeout. If the first invocation times out before the Worker registers the Task Queue, the binding is never created and the Worker is never invoked again. → `references//setup.md` for the exact default. - **Use an immutable, versioned build per Build ID in production.** Pointing the provider at a mutable "latest" target lets code change under in-flight Workflows and cause non-determinism errors, even for Pinned Workflows. Keep a 1-to-1 mapping between each Build ID and one immutable build. → `references//versioning.md`. -- **Tune the timeout triple together for long-running Activities:** (1) worker stop timeout > longest Activity runtime, (2) shutdown deadline buffer > worker stop timeout + shutdown hook time, (3) invocation deadline > longest Activity runtime + shutdown deadline buffer. Raising one alone does not help. If the longest Activity exceeds half the maximum invocation deadline, recommend Activity Heartbeats. → `references/concepts.md`, `references/sdk-configuration.md`. +- **Tune the timeout triple together for long-running Activities:** (1) worker stop timeout > longest Activity runtime, (2) shutdown deadline buffer > worker stop timeout + shutdown hook time, (3) invocation deadline > longest Activity runtime + shutdown deadline buffer. Raising one alone does not help. If the longest Activity exceeds half the maximum invocation deadline, recommend Activity Heartbeats. → `references/concepts.md`, `references//sdk-.md`. - **Eager Activities are always disabled** — serverless invocations don't maintain persistent connections. Don't suggest them as an optimization. - **Activities are bounded by the invocation limit** (minus the shutdown deadline buffer); Workflow duration is unbounded and can span many invocations. Flag Activities that approach the provider's limit early. → `references/concepts.md`. - **Mixed serverless + long-lived Workers on one Task Queue:** do not enable dynamic scaling on the long-lived Workers — the two groups can't coordinate scaling and will cause unnecessary invocations. @@ -214,14 +221,17 @@ Most questions need 2–3 reference files. | User intent | Reference file(s) | |---|---| | What is a Serverless Worker / the WCI? How do invocation and autoscaling work? What are the constraints? Serverless vs long-lived Workers? | `references/concepts.md` | -| Deploy a Serverless Worker (happy path): write code, package, deploy, register + set-current version, verify, tear down. | `references//setup.md` (+ `references/concepts.md`) | +| Deploy a Serverless Worker (happy path): write code, package, deploy, register + set-current version, verify, tear down. | `references//setup.md` + the selected `references//sdk-.md` (+ `references/concepts.md`) | | Operator permissions and preflight; execution role vs Temporal invocation role; CloudFormation (Cloud + self-hosted). | `references//iam.md` | | Update or redeploy; version the build, use a qualified ARN, roll back. | `references//versioning.md` (+ `references/concepts.md`) | | Self-hosted server enablement (dynamic config, WCI, server AWS credentials). | `references//self-hosted.md` (+ `references//iam.md`) | -| SDK-specific options and tuned defaults, which package to install and how it is distributed, imports, versioning-behavior configuration, connection config (TOML, env vars). Reduce cold start / pre-bundle Workflow code. | `references/sdk-configuration.md` | -| Add OpenTelemetry observability, collector config, tracing. | `references//observability.md` | -| Worker not invoked, Workflows not progressing, inspect the WCI. | `references//diagnostics.md` (+ `references/concepts.md`) | -| Long-running Activities and timeout relationships. Isolate Activities from resource exhaustion. | `references/concepts.md` (+ `references/sdk-configuration.md`) | +| Go SDK-specific options and tuned defaults, package and import, API inspection, handler, build and packaging, runtime and deployment values, versioning-behavior configuration, connection config, OpenTelemetry integration. | `references//sdk-go.md` | +| Python SDK-specific options and tuned defaults, package and import, API inspection, handler, build and packaging, runtime and deployment values, versioning-behavior configuration, connection config, OpenTelemetry integration, diagnostic signatures. | `references//sdk-python.md` | +| TypeScript SDK-specific options and tuned defaults, package and import, API inspection, handler, build and packaging, runtime and deployment values, versioning-behavior configuration, connection config, pre-bundled Workflow code, OpenTelemetry integration. | `references//sdk-typescript.md` | +| Java SDK-specific options and tuned defaults, artifact and imports, API inspection, handler, build and packaging, runtime and deployment values, versioning-behavior configuration, connection config, OpenTelemetry integration, logging and diagnostic signatures. | `references//sdk-java.md` | +| Add OpenTelemetry observability, Collector config, X-Ray, and IAM. | `references//observability.md` + the selected `references//sdk-.md` | +| Worker not invoked, Workflows not progressing, inspect the WCI. | `references//diagnostics.md` + the selected `references//sdk-.md` (+ `references/concepts.md`) | +| Long-running Activities and timeout relationships. Isolate Activities from resource exhaustion. | `references/concepts.md` (+ the selected `references//sdk-.md`) | ## Out of Scope diff --git a/references/aws-lambda/diagnostics.md b/references/aws-lambda/diagnostics.md index e5459d8..b1d2750 100644 --- a/references/aws-lambda/diagnostics.md +++ b/references/aws-lambda/diagnostics.md @@ -127,27 +127,7 @@ Common errors include: **No application logs at all, but the Worker clearly ran.** Two different SDKs produce this same misleading silence by unrelated mechanisms, and in both cases the Worker is healthy — only the logging is broken. Diagnose invocation health from Lambda's own runtime markers (`INIT_START`/`START`/`END`/`REPORT`) and CloudWatch metrics instead, then fix the binding. -| SDK | Cause | Fix | -|---|---|---| -| Python | `logging.basicConfig()` is a no-op when a root handler already exists, and the Lambda runtime installs one before your module is imported — so the level never changes and `INFO` records are filtered out | `logging.getLogger().setLevel(logging.INFO)` | -| Java | The SDK compiles against `slf4j-api` **1.7.36**; a 2.x provider (`slf4j-simple:2.x`, Logback 1.3+) does not bind to a 1.7 API and nothing is emitted | use a 1.7.x provider, e.g. `org.slf4j:slf4j-simple:1.7.36` | - -**Java — `NullPointerException` in `ShutdownManager` on every invocation (benign).** As of `temporal-aws-lambda` 1.38.0, a normal graceful shutdown logs a `WARN` with a full stack trace: - -``` -[main] WARN io.temporal.internal.worker.ShutdownManager - Exception during waiting for termination -java.lang.NullPointerException: Cannot invoke "SuspendableWorker.awaitTermination(long, TimeUnit)" - because "this.workerCommandWorker" is null - at io.temporal.worker.WorkerFactory.lambda$awaitTermination$12(WorkerFactory.java:519) - at io.temporal.aws.lambda.DefaultLambdaWorkerRuntime$DefaultInvocation.awaitTermination(...:82) - at io.temporal.aws.lambda.LambdaWorker$Handler.shutdownInvocation(LambdaWorker.java:323) -``` - -This is **not** a failure. It appears *after* Tasks have completed, is followed by `Temporal Lambda worker stopped`, a clean `END`/`REPORT`, and no timeout; Workflows complete correctly. Do not change configuration, IAM, or timeouts in response to it. Confirm it is benign by checking that the Workflow completed and that `REPORT` shows a duration below the deadline, then ignore it. - -**Java — `ClassNotFoundException` / `NoClassDefFoundError` at first invocation.** The uber-jar was built without merging `META-INF/services`, or the handler string is wrong. Check the handler format first: Java uses `fully.qualified.Class::method`, not the `module.function` form every other SDK uses. Then verify the services merge — `unzip -p META-INF/services/io.grpc.ManagedChannelProvider` should list more than one provider. → `setup.md` (Java packaging). - -**Java — exec-format or `UnsupportedClassVersionError` at first invocation.** Bytecode targets a newer JDK than the runtime. Set `` (or the Gradle toolchain) to match `--runtime`. +For SDK-specific diagnostics, see the selected SDK reference. ### Check for Lambda timeout diff --git a/references/aws-lambda/observability.md b/references/aws-lambda/observability.md index 9b61c3f..6d8537f 100644 --- a/references/aws-lambda/observability.md +++ b/references/aws-lambda/observability.md @@ -1,196 +1,28 @@ -# Observability for Serverless Workers - - +# Observability for AWS Lambda Serverless Workers ## Overview Each SDK provides an OpenTelemetry integration package with defaults configured for the AWS Distro for OpenTelemetry (ADOT) Lambda layer. When enabled, the Worker emits SDK metrics and distributed traces for Workflow and Activity executions. The ADOT Lambda layer collects this telemetry and can forward traces to AWS X-Ray and metrics to Amazon CloudWatch. -## Go SDK - -### OTel package - -Import: `otel "go.temporal.io/sdk/contrib/aws/lambdaworker/otel"` - -### OTel functions - -- `otel.ApplyDefaults` — configures both metrics and tracing. -- `otel.ApplyMetrics` — configures metrics only. -- `otel.ApplyTracing` — configures tracing only. - -Usage in the configure callback: - -```go -if err := otel.ApplyDefaults(opts, &opts.ClientOptions, otel.Options{}); err != nil { - return err -} -``` - -By default, telemetry is sent to `localhost:4317`, which is the ADOT Lambda layer's default collector endpoint. - -### ADOT layer setup (Go) - -Attach the ADOT Collector layer to your Lambda function. -Go does not need a language-specific ADOT layer because the OTel SDK is compiled into the binary. - -### Collector config env var (Go) - -`OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/otel-collector-config.yaml` - ---- - -## Python SDK - -### OTel package - -Import: `from temporalio.contrib.aws.lambda_worker.otel import apply_defaults` - -To install with OTel support: `pip install temporalio[lambda-worker-otel]` - -### OTel functions - -- `apply_defaults` — configures both metrics and tracing. -- `build_metrics_telemetry_config` — configures metrics only. -- `apply_tracing` — configures tracing only. - -Usage in the configure callback: - -```python -def configure(config: LambdaWorkerConfig) -> None: - config.worker_config["task_queue"] = TASK_QUEUE - config.worker_config["workflows"] = [SampleWorkflow] - config.worker_config["activities"] = [hello_activity] - apply_defaults(config) -``` - -By default, telemetry is sent to `localhost:4317`, which is the ADOT Lambda layer's default collector endpoint. - -### ADOT layer setup (Python) - -Attach the ADOT Python Lambda layer to your Lambda function. The layer includes both auto-instrumentation and an OpenTelemetry Collector that receives telemetry on `localhost:4317` and forwards traces to AWS X-Ray and metrics to Amazon CloudWatch. - -### Collector config env var (Python) - -`OPENTELEMETRY_COLLECTOR_CONFIG_FILE=/var/task/otel-collector-config.yaml` - -Note: Python uses `_FILE` while Go and TypeScript use `_URI`. - ---- - -## Java SDK - -### OTel package - -No extra dependency is required: `temporal-aws-lambda` already depends on `io.temporal:temporal-opentelemetry`, `io.opentelemetry:opentelemetry-api` (BOM 1.25.0), and `io.opentelemetry.contrib:opentelemetry-aws-xray`. The helper class ships inside the module. - -Import: `io.temporal.aws.lambda.OtelLambdaWorkerConfigurationHelper` - -### OTel functions - - - -- `configure(LambdaWorkerOptions.Builder)` — configures metrics and tracing with defaults. -- `configure(LambdaWorkerOptions.Builder, Consumer)` — same, with customization. -- `configureMetrics(LambdaWorkerOptions.Builder, OpenTelemetry)` — metrics only (an overload also takes a service name and a `Duration` report interval). -- `configureTracing(LambdaWorkerOptions.Builder, OpenTelemetry)` — tracing only. -- `configureFlushHook(LambdaWorkerOptions.Builder, OpenTelemetry, Duration)` — registers a flush before the invocation ends. - -Its own `newBuilder()` exposes `setOpenTelemetry`, `setEndpoint`, `setServiceName`, `setMetricsReportInterval`, `setFlushTimeout`, and `setFlushHook`. - -Usage in the cold-start configure callback: +Load the selected SDK reference's **Observability** section: -```java -LambdaWorker.define( - new WorkerDeploymentVersion("my-app", "build-1"), - builder -> { - builder.setTaskQueue("my-task-queue"); - builder.registerWorkflowImplementationTypes(MyWorkflowImpl.class); - builder.registerActivitiesImplementations(new MyActivitiesImpl()); - OtelLambdaWorkerConfigurationHelper.configure(builder); - }); -``` - -Defaults come from the constants `DEFAULT_OTLP_ENDPOINT` and `DEFAULT_SERVICE_NAME`, and the helper reads `OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_SERVICE_NAME`, and `AWS_LAMBDA_FUNCTION_NAME` from the environment. As with the other SDKs, the default endpoint is the ADOT layer's collector on `localhost:4317`. - -**Flush before the deadline.** A Serverless Worker's invocation ends on a deadline rather than after a request, so telemetry buffered past that point is lost. Use `configureFlushHook` (or a report interval shorter than the invocation deadline) so metrics and spans are exported before shutdown. This matters more on Java's shorter recommended deadline (90s) than on the 600s used elsewhere. - -### ADOT layer setup (Java) - -Attach the ADOT Collector layer. Because the OpenTelemetry SDK arrives as an ordinary Maven dependency of `temporal-aws-lambda`, no language-specific auto-instrumentation layer is required for the Worker's own telemetry — the same situation as Go. - -### Collector config env var (Java) - -`OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/otel-collector-config.yaml` — the `_URI` form, as with Go and TypeScript. The official Java sample packages `otel-collector-config.template.yaml` into the artifact root as `otel-collector-config.yaml` during `shadowJar`; with Maven, add it under `src/main/resources`. - ---- - -## TypeScript SDK - -### OTel package - -Import: `import { applyDefaults } from '@temporalio/lambda-worker/otel'` - -### OTel functions - -- `applyDefaults` — registers Temporal SDK interceptors for tracing and configures the Core SDK to export metrics via OTLP. -- `makeOtelPlugin` — returns a plugin for pre-bundling Workflow code that includes Workflow interceptor modules. - -Usage in the configure callback: - -```typescript -export const handler = runWorker({ deploymentName: 'sdk-demo', buildId: 'v1' }, (config) => { - config.workerOptions.taskQueue = TASK_QUEUE; - config.workerOptions.workflowBundle = { - codePath: require.resolve('./workflow-bundle.js'), - }; - config.workerOptions.activities = activities; - applyDefaults(config); -}); -``` - -By default, telemetry is sent to `localhost:4317`, which is the ADOT Lambda layer's default collector endpoint. - -### Pre-bundling with OTel - -When pre-bundling Workflow code, pass the plugin from `makeOtelPlugin()` so that Workflow interceptor modules are included in the bundle: - -```typescript -import { bundleWorkflowCode } from '@temporalio/worker'; -import { makeOtelPlugin } from '@temporalio/lambda-worker/otel'; - -const { plugin } = makeOtelPlugin(); -const { code } = await bundleWorkflowCode({ - workflowsPath: require.resolve('./workflows'), - plugins: [plugin], -}); -``` - - -### ADOT layer setup (TypeScript) - -Attach two ADOT Lambda layers: - -1. The ADOT JavaScript layer for Node.js-side auto-instrumentation and trace export. -2. The ADOT Collector layer (`aws-otel-collector-amd64`) to run the OTel Collector as a Lambda extension, receiving telemetry via OTLP on `localhost:4317` and forwarding traces to X-Ray and metrics to CloudWatch. - -### Collector config env var (TypeScript) - -`OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/otel-collector-config.yaml` - ---- +| SDK | Observability reference | +|---|---| +| Go | `sdk-go.md` → Observability | +| Python | `sdk-python.md` → Observability | +| TypeScript | `sdk-typescript.md` → Observability | +| Java | `sdk-java.md` → Observability | -## Common across all SDKs +The remaining steps in this file are shared across SDKs. -### Custom Collector configuration required +## Custom Collector configuration required The default ADOT Collector configuration does not route OpenTelemetry Protocol (OTLP) data to the traces pipeline. You must provide a custom Collector configuration that wires the OTLP receiver to both the traces and metrics pipelines. Example `otel-collector-config.yaml` (bundle in your Lambda deployment package): +For the Collector configuration environment variable, see the selected SDK reference. + ```yaml receivers: otlp: @@ -228,7 +60,7 @@ service: ``` -### Enable X-Ray active tracing +## Enable X-Ray active tracing ```bash aws lambda update-function-configuration \ @@ -237,7 +69,7 @@ aws lambda update-function-configuration \ ``` -### Required IAM permissions +## Required IAM permissions The Lambda execution role must have permissions to write to X-Ray and CloudWatch: @@ -247,28 +79,4 @@ The Lambda execution role must have permissions to write to X-Ray and CloudWatch Without these permissions, the Collector fails silently and no telemetry appears. -For Python, the `AWSXRayDaemonWriteAccess` managed policy can be attached instead. - -### Collector config env var summary - - - -| SDK | Environment variable | -|---|---| -| Go | `OPENTELEMETRY_COLLECTOR_CONFIG_URI` | -| Python | `OPENTELEMETRY_COLLECTOR_CONFIG_FILE` | -| TypeScript | `OPENTELEMETRY_COLLECTOR_CONFIG_URI` | -| Java | `OPENTELEMETRY_COLLECTOR_CONFIG_URI` | - -### ADOT layer summary - -| SDK | Layers needed | -|---|---| -| Go | ADOT Collector layer only (no language-specific layer; OTel SDK is compiled into the binary) | -| Python | ADOT Python Lambda layer (includes collector and auto-instrumentation) | -| TypeScript | ADOT JavaScript layer + ADOT Collector layer (`aws-otel-collector-amd64`) | -| Java | ADOT Collector layer only (no language-specific layer; the OTel SDK is a Maven dependency of `temporal-aws-lambda`) | - - - - +For language-specific IAM notes, see the selected SDK reference. diff --git a/references/aws-lambda/sdk-go.md b/references/aws-lambda/sdk-go.md new file mode 100644 index 0000000..8a2216e --- /dev/null +++ b/references/aws-lambda/sdk-go.md @@ -0,0 +1,192 @@ +# Go SDK on AWS Lambda + + + +Use this reference for Go SDK-specific package, entry-point, Worker configuration, tuned defaults, and observability details. For shared AWS Lambda deployment and observability infrastructure, see `setup.md` and `observability.md`. + +## Package + +Import: `lambdaworker "go.temporal.io/sdk/contrib/aws/lambdaworker"` + +Install: `go get go.temporal.io/sdk/contrib/aws/lambdaworker` — **this is a separate Go module** from `go.temporal.io/sdk`, versioned independently (`v0.1.1` at the time of writing). Having the main SDK in `go.mod` does not make it importable; add it explicitly, then `go mod tidy`. Verify the installed surface with `go doc go.temporal.io/sdk/contrib/aws/lambdaworker` before generating code — the API is Public Preview and drifts. + +- Go: [Go Lambda Worker sample](https://github.com/temporalio/samples-go/tree/main/lambda-worker) + +List the exported API of the installed module version before generating code: + +```bash +go doc go.temporal.io/sdk/contrib/aws/lambdaworker +go doc go.temporal.io/sdk/contrib/aws/lambdaworker.Options +``` + +**A useful ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs — Java's is `define`, not "run"-shaped like the others — so check rather than pattern-match from another language. + +## Entry point + +`lambdaworker.RunWorker` — starts a Lambda-based Worker. Pass a `WorkerDeploymentVersion` and a callback that registers Workflows and Activities. + +## Configure callback + +The `Options` callback gives access to the same registration methods as a traditional Worker: `RegisterWorkflow`, `RegisterWorkflowWithOptions`, `RegisterActivity`, `RegisterActivityWithOptions`, and `RegisterNexusService`. + +Go, Python and TypeScript invoke it per invocation. + +In Go it is a direct field on the options object (`opts.TaskQueue`). + +## Versioning behavior + +Set per-Workflow at registration time with `workflow.VersioningBehaviorPinned` or `workflow.VersioningBehaviorAutoUpgrade`. +Or set a Worker-level default with `DefaultVersioningBehavior` in `DeploymentOptions`. + +**Worker Versioning is always on.** The run-worker entry point enables it, so the only remaining decision is `Pinned` vs `AutoUpgrade` per Workflow (or a Worker-level default). + +## Handler example + +Use the Go SDK's `lambdaworker` package. + +```go +package main + +import ( + lambdaworker "go.temporal.io/sdk/contrib/aws/lambdaworker" + "go.temporal.io/sdk/worker" + "go.temporal.io/sdk/workflow" +) + +func main() { + lambdaworker.RunWorker(worker.WorkerDeploymentVersion{ + DeploymentName: "my-app", + BuildID: "build-1", + }, func(opts *lambdaworker.Options) error { + opts.TaskQueue = "my-task-queue" + + opts.RegisterWorkflowWithOptions(MyWorkflow, workflow.RegisterOptions{ + VersioningBehavior: workflow.VersioningBehaviorPinned, + }) + opts.RegisterActivity(MyActivity) + + return nil + }) +} +``` + + +## Lambda-tuned defaults + + + +| Setting | Lambda default | +|---|---| +| `MaxConcurrentActivityExecutionSize` | 2 | +| `MaxConcurrentWorkflowTaskExecutionSize` | 10 | +| `MaxConcurrentLocalActivityExecutionSize` | 2 | +| `MaxConcurrentNexusTaskExecutionSize` | 5 | +| `MaxConcurrentActivityTaskPollers` | 1 | +| `MaxConcurrentWorkflowTaskPollers` | 2 | +| `MaxConcurrentNexusTaskPollers` | 1 | +| `WorkerStopTimeout` | 5 seconds | +| `DisableEagerActivities` | Always true | +| Sticky cache size | 100 | +| `ShutdownDeadlineBuffer` | 7 seconds | + +Note: Go sticky cache size is 100, while Python and TypeScript are 30. These values come from each SDK's own docs and are not interchangeable. + +These are the same `worker.Options` available to any Temporal Worker, just with lower values for Lambda's constrained environment. Except for `ShutdownDeadlineBuffer`, which is specific to the `lambdaworker` package. + +`DisableEagerActivities` is always true and cannot be overridden. Eager Activities require a persistent connection, which Lambda invocations don't maintain. + +`ShutdownDeadlineBuffer` controls how much time before the Lambda deadline the Worker begins its graceful shutdown. The default is `WorkerStopTimeout` + 2 seconds. + +If your Worker handles long-running Activities, increase `WorkerStopTimeout`, `ShutdownDeadlineBuffer`, and the Lambda invocation deadline (`--timeout`) together. + +## Connection configuration + +The `lambdaworker` package automatically loads Temporal client configuration from a TOML config file and environment variables (see the Environment Configuration docs, `/develop/environment-configuration`). + +TOML config file resolution order: + +1. `TEMPORAL_CONFIG_FILE` environment variable, if set. +2. `temporal.toml` in `$LAMBDA_TASK_ROOT` (typically `/var/task`). +3. `temporal.toml` in the current working directory. + +The file is optional. If absent, only environment variables are used. + +## Build and package + +Cross-compile for Lambda's Linux runtime: + +```bash +GOOS=linux GOARCH=amd64 go build -tags lambda.norpc -o bootstrap ./worker +``` + + +Package the binary into a zip file: + +```bash +zip function.zip bootstrap +``` + + +**Add `CGO_ENABLED=0`, and match the architecture you deploy.** The `provided.al2023` runtime expects a self-contained binary; building with cgo enabled links against host libraries that may not resolve inside the runtime. Set `CGO_ENABLED=0` for a statically linked binary, and keep `GOARCH` consistent with the function's `--architectures` (`amd64` ↔ `x86_64`, `arm64` ↔ `arm64`). Also adjust the trailing package path to your layout — `.` when `main` is in the repo root, `./worker` when it is in a `worker/` subdirectory. A reusable script: + +```bash +#!/usr/bin/env bash +set -euo pipefail +go vet ./... # catches a missing import before the cross-compile +CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -tags lambda.norpc -o bootstrap . +zip -q function.zip bootstrap +file bootstrap # expect: ELF 64-bit ... statically linked +``` + +Run `go vet` (or a plain `go build ./...`) before the packaging build. The three-package import block above — `lambdaworker`, `worker` for `WorkerDeploymentVersion`, and `workflow` for the versioning-behavior constants — is easy to write short by one entry, and catching that locally is faster than discovering it in the cross-compile step. + +An architecture mismatch surfaces only at invocation time as an `Runtime.InvalidEntrypoint`/exec-format error, not at build or package time — the same failure class as the Python wheel mismatch described in `sdk-python.md`. + +A typical Go Worker zip lands around 10–15 MB, well under the 50 MB direct-upload limit. + +## Deploy the Lambda function + +```bash +aws lambda create-function \ + --function-name my-temporal-worker \ + --runtime provided.al2023 \ + --handler bootstrap \ + --role \ + --zip-file fileb://function.zip \ + --timeout 600 \ + --memory-size 256 \ + --environment '{"Variables":{"HOME":"/tmp","TEMPORAL_ADDRESS":":7233","TEMPORAL_NAMESPACE":"","TEMPORAL_API_KEY":""}}' +``` + + +- `--runtime`: `provided.al2023` for custom Go binaries. +- `--handler`: `bootstrap` when using the `provided.al2023` custom runtime. + +| Variable | Description | +|---|---| +| `HOME` | Set to `/tmp` in the Go and TypeScript examples above. Lambda's filesystem is read-only outside `/tmp`, so anything the runtime or config loader resolves relative to the home directory needs a writable target. The docs omit it from the Python example; including it there is harmless. | + +## Observability + +Import: `otel "go.temporal.io/sdk/contrib/aws/lambdaworker/otel"` + +- `otel.ApplyDefaults` — configures both metrics and tracing. +- `otel.ApplyMetrics` — configures metrics only. +- `otel.ApplyTracing` — configures tracing only. + +Usage in the configure callback: + +```go +if err := otel.ApplyDefaults(opts, &opts.ClientOptions, otel.Options{}); err != nil { + return err +} +``` + +By default, telemetry is sent to `localhost:4317`, which is the ADOT Lambda layer's default collector endpoint. + +Attach the ADOT Collector layer to your Lambda function. +Go does not need a language-specific ADOT layer because the OTel SDK is compiled into the binary. + +`OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/otel-collector-config.yaml` + +For the shared Collector configuration, X-Ray enablement, and execution-role permissions, see `observability.md`. diff --git a/references/aws-lambda/sdk-java.md b/references/aws-lambda/sdk-java.md new file mode 100644 index 0000000..a1359c2 --- /dev/null +++ b/references/aws-lambda/sdk-java.md @@ -0,0 +1,318 @@ +# Java SDK on AWS Lambda + + + +Use this reference for Java SDK-specific package, entry-point, Worker configuration, tuned defaults, observability, and diagnostic details. For shared AWS Lambda deployment, observability infrastructure, and diagnostic flow, see `setup.md`, `observability.md`, and `diagnostics.md`. + +## Package + +Import: `io.temporal.aws.lambda.LambdaWorker`, `io.temporal.aws.lambda.LambdaWorkerOptions`, `io.temporal.common.WorkerDeploymentVersion` + +Install: `io.temporal:temporal-aws-lambda` — a **separate Maven artifact** from `io.temporal:temporal-sdk`, but published on the **same version line** (both 1.38.0). This is a third packaging pattern: unlike Go and TypeScript it is not independently versioned, and unlike Python it does not ship inside the main SDK. Use `io.temporal:temporal-bom` in `dependencyManagement` to keep them aligned. + +```xml + + + + io.temporaltemporal-bom + 1.38.0pomimport + + + +``` + +`aws-lambda-java-core` (1.4.0) arrives transitively from `temporal-aws-lambda`; declare it explicitly if you compile against `RequestHandler`/`Context`. + +- Java: [Java Lambda Worker sample](https://github.com/temporalio/samples-java/tree/main/lambda-worker) — three Gradle subprojects (`worker/` handler + greeting Workflow/Activity, `starter/` local client, `deploy/` IAM and deploy scripts plus a CloudFormation template) + +List the real public API of the resolved artifact before generating code: + +```bash +javap -cp ~/.m2/repository/io/temporal/temporal-aws-lambda//temporal-aws-lambda-.jar \ + io.temporal.aws.lambda.LambdaWorker +javap -cp 'io.temporal.aws.lambda.LambdaWorkerOptions$Builder' +# or read the source directly — Maven Central publishes a sources jar: +# curl -O https://repo1.maven.org/maven2/io/temporal/temporal-aws-lambda//temporal-aws-lambda--sources.jar +``` + +**A useful ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs — Java's is `define`, not "run"-shaped like the others — so check rather than pattern-match from another language. + +## Entry point + +**`LambdaWorker.define(version, configure)`** — returns a `RequestHandler` that your handler class delegates to. There are four public overloads: `define` (2- and 3-arg) and `newHandler` (2- and 3-arg, taking a pre-built `LambdaWorkerOptions`). + +Note that Java's entry point is not "run"-shaped like the other SDKs' (`RunWorker`, `run_worker`, `runWorker`) — confirm the method name against the version you install. + +## Configure callback — two phases, unlike the other SDKs + +Java splits configuration in a way no other SDK does, and the distinction matters: + +- The `Consumer` passed to `define` is *"invoked once while the Lambda handler is constructed"* — i.e. at **cold start**, once per container, **not** per invocation. +- Per-invocation configuration is a **separate** callback, `LambdaWorker.InvocationConfigurator`, taking `(LambdaWorkerOptions.Builder, com.amazonaws.services.lambda.runtime.Context)`, *"invoked for each Lambda invocation before Temporal service stubs, client, and worker are created."* Use the 3-arg `define` overload for it. + +Contrast Python, whose `configure` runs **once per invocation**. Do not describe them as equivalent, and do not carry per-invocation logic into Java's cold-start callback. + +Registration methods on `LambdaWorkerOptions.Builder`: `setTaskQueue`, `registerWorkflowImplementationTypes`, `registerDynamicWorkflowImplementationType`, `registerWorkflowImplementationFactory` (3 overloads), `registerActivitiesImplementations`, `registerDynamicActivityImplementation`, `registerNexusServiceImplementation`, `addShutdownHook`, plus `getWorkerOptionsBuilder()` / `getWorkflowClientOptionsBuilder()` / `getWorkflowServiceStubsOptionsBuilder()` for lower-level tuning. + +## Versioning behavior + +Per-Workflow via the **annotation** `io.temporal.workflow.WorkflowVersioningBehavior` on the workflow method, taking `io.temporal.common.VersioningBehavior.PINNED` or `.AUTO_UPGRADE`: + +```java +public class GreetingWorkflowImpl implements GreetingWorkflow { + @Override + @WorkflowVersioningBehavior(VersioningBehavior.PINNED) + public String getGreeting(String name) { ... } +} +``` + +Or a Worker-level default with `DefaultVersioningBehavior` in `DeploymentOptions`. + +**Worker Versioning is always on.** The run-worker entry point enables it, so the only remaining decision is `Pinned` vs `AutoUpgrade` per Workflow (or a Worker-level default). + +Versioning behavior: annotate the Workflow **method** in the implementation class with `io.temporal.workflow.WorkflowVersioningBehavior`, or set a Worker-level default with `DefaultVersioningBehavior` in `DeploymentOptions`. + +```java +public class MyWorkflowImpl implements MyWorkflow { + @Override + @WorkflowVersioningBehavior(VersioningBehavior.PINNED) + public String getGreeting(String name) { ... } +} +``` + +## Handler example + +Use the `temporal-aws-lambda` module. The handler class implements `RequestHandler` and delegates to the handler returned by `LambdaWorker.define`. + +```java +package com.example.temporal; + +import com.amazonaws.services.lambda.runtime.Context; +import com.amazonaws.services.lambda.runtime.RequestHandler; +import io.temporal.aws.lambda.LambdaWorker; +import io.temporal.common.WorkerDeploymentVersion; + +public final class LambdaFunction implements RequestHandler { + + // The callback below runs ONCE, at cold start, when the handler is constructed -- + // not per invocation. Use the 3-arg define(...) overload with an + // InvocationConfigurator for anything that must run per invocation. + private static final RequestHandler WORKER = + LambdaWorker.define( + new WorkerDeploymentVersion("my-app", "build-1"), + builder -> { + builder.setTaskQueue("my-task-queue"); + builder.registerWorkflowImplementationTypes(MyWorkflowImpl.class); + builder.registerActivitiesImplementations(new MyActivitiesImpl()); + }); + + @Override + public Void handleRequest(Object input, Context context) { + return WORKER.handleRequest(input, context); + } +} +``` + +The entry point is `define` (or `newHandler` for pre-built options) — not a "run"-shaped name like the other SDKs use. Temporal's [sample handler](https://github.com/temporalio/samples-java/blob/main/lambda-worker/worker/src/main/java/io/temporal/samples/lambdaworker/LambdaFunction.java) is the reference implementation. + +## Lambda-tuned defaults + + + +| Setting | Lambda default | +|---|---| +| `MaxConcurrentActivityExecutionSize` | 2 | +| `MaxConcurrentWorkflowTaskExecutionSize` | 10 | +| `MaxConcurrentLocalActivityExecutionSize` | 2 | +| `MaxConcurrentNexusExecutionSize` | 5 | +| `MaxConcurrentWorkflowTaskPollers` | 2 | +| `MaxConcurrentActivityTaskPollers` | 1 | +| `MaxConcurrentNexusTaskPollers` | 1 | +| `WorkflowCacheSize` | 30 | +| `MaxWorkflowThreadCount` | 30 | +| `GracefulShutdownTimeout` | 5 seconds | +| `ShutdownDeadlineBuffer` | 7 seconds | + +`MaxWorkflowThreadCount` has no counterpart in the other SDKs — Java runs Workflow code on real threads. + +Eager Activities are disabled: `builder.setDisableEagerExecution(true)` (`LambdaWorkerOptions.java:258`). `ShutdownDeadlineBuffer` defaults to `GracefulShutdownTimeout` + 2s, the same relationship as the other SDKs. + +## Logging — the binding must be SLF4J 1.7.x + +The Java SDK compiles against `org.slf4j:slf4j-api:1.7.36`. A 2.x provider (`slf4j-simple:2.x`, Logback 1.3+) **will not bind to a 1.7 API**, and the Worker runs with no logs at all — the same silent outcome as Python's `logging.basicConfig()` no-op, by a different mechanism. Use a 1.7.x provider: + +```xml + + org.slf4jslf4j-simple1.7.36 + +``` + +With a correct binding the module logs its own lifecycle unprompted, which is more than the other SDKs give you by default: + +``` +[main] INFO io.temporal.aws.lambda.LambdaWorker - Temporal Lambda worker started + awsRequestId= invokedFunctionArn= taskQueue= identity=@ +``` + +## Connection configuration + +Loaded automatically from environment variables and an optional TOML config file. Public constants on `LambdaWorkerOptions`: `TEMPORAL_TASK_QUEUE`, `TEMPORAL_CONFIG_FILE`, `LAMBDA_TASK_ROOT`. + +Resolution order (`LambdaWorkerOptions.resolveConfigFilePath`): + +1. `TEMPORAL_CONFIG_FILE` environment variable, if set. +2. `temporal.toml` in `$LAMBDA_TASK_ROOT` (typically `/var/task`). +3. `temporal.toml` in the current working directory. + +**`HOME=/tmp` is not required for Java** — unlike the Go and TypeScript examples. The module never reads `HOME`; when no file is found it passes a null path to `ClientConfig.load`, which falls back to `/.config/temporalio/temporal.toml` and treats both a missing home directory and a `FileNotFoundException` as "empty config, no error". It is a read, not a write, so Lambda's read-only filesystem is not involved. Note also that Java reads the `user.home` **system property**, not the `HOME` environment variable, so setting `HOME` is not even the right lever — use `-Duser.home` via `JAVA_TOOL_OPTIONS` if you ever need to steer it. + +## Build and package + +Build an uber-jar with all dependencies bundled. A JAR is a valid zip, so it uploads directly with no extra packaging step. + +**Gradle** (what the official sample uses): `./gradlew shadowJar` → `build/libs/-all.jar`. + +**Maven**: `maven-shade-plugin`, bound to `package` → `target/.jar`. + +```xml + + org.apache.maven.plugins + maven-shade-plugin + 3.6.0 + + + package + shade + + false + + + + + + *:* + + META-INF/*.SF + META-INF/*.DSA + META-INF/*.RSA + module-info.class + + + + + + + +``` + +**`ServicesResourceTransformer` is mandatory, not hygiene.** The Temporal client is gRPC-based, and gRPC discovers channel providers, name resolvers, and load balancers through `META-INF/services` files that several jars each contribute to. Without merging, later copies overwrite earlier ones and the client fails at the **first invocation** with a "no functional channel service provider found"-class error — never at build time. Verify the merge before uploading: + +```bash +unzip -p target/.jar META-INF/services/io.grpc.ManagedChannelProvider +# expect MORE THAN ONE provider line, e.g.: +# io.grpc.netty.shaded.io.grpc.netty.NettyChannelProvider +# io.grpc.netty.shaded.io.grpc.netty.UdsNettyChannelProvider +``` + +Excluding the signature files matters too: signed-jar signatures are invalid inside an uber-jar and produce a `SecurityException` at class load. + +**Match the bytecode target to the runtime.** Compiling on a newer JDK than the function's runtime needs an explicit target — `17` for `--runtime java17`. This is the Java form of the architecture/wheel mismatch: it fails at invocation, not at build. + +**Watch the artifact size — Java hits the 50 MB direct-upload ceiling early.** A hello-world Worker (one Workflow, one Activity, `slf4j-simple`) measured **41 MB**, versus ~14 MB for the equivalent Python package and 10–15 MB for Go. Anything with real dependencies will exceed 50 MB and must be uploaded via S3 (`--code S3Bucket=…,S3Key=…`) rather than `--zip-file fileb://`. Check before deploying: + +```bash +ls -lh target/.jar +``` + +## Deploy the Lambda function + +```bash +aws lambda create-function \ + --function-name my-temporal-worker \ + --runtime java17 \ + --architectures x86_64 \ + --handler com.example.temporal.LambdaFunction::handleRequest \ + --role \ + --zip-file fileb://target/my-worker.jar \ + --timeout 90 \ + --memory-size 1024 \ + --environment file:///tmp/lambda-env.json +``` + +- `--runtime`: `java17` (or another supported Java version). +- `--handler`: `fully.qualified.Class::method` — **a different format from every other SDK**, which use `module.function` / `module.export`. Point it at the method that delegates to the `LambdaWorker.define` handler. +- `--zip-file`: the shaded jar directly; no separate zip step. Switch to `--code S3Bucket=…,S3Key=…` once the jar exceeds 50 MB, which happens early in Java (see packaging above). +- **`HOME=/tmp` is not needed** — unlike the Go and TypeScript examples. Verified: the Java module never reads `HOME`, and a missing config file is non-fatal. → Connection configuration above. +- `--memory-size`: the docs recommend starting at `1024` because "Java Workers typically need more memory than other runtimes," then adjusting from CloudWatch. A measured hello-world used **240 MB of 1024** (`Max Memory Used` in the invocation's REPORT line), so `512` is usually ample for small Workers — and since Lambda bills GB-seconds, halving memory halves the bill. Start at 1024, read the metric, then cut. + + + +**`--timeout` is a cost setting once it clears startup.** The per-SDK examples differ deliberately — 600 for Go, Python and TypeScript; 90 for Java — and both clear startup easily: a measured Java Worker bound its Task Queue **~10s** after `create-version`, JVM cold start included, against the 83s of polling a 90s deadline allows. Lambda's 3-second default is what fails this; 90 does not. + +Measured cold starts are ~1s for Python and Java alike (`Init Duration` in the REPORT line). + +| SDK example | Memory | Full invocation | GB-seconds | +|---|---|---|---| +| Java 90s / 1024 MB | 1 GB | ~84 s billed | ~84 | + +**Memory is the multiplier, not the deadline.** 1024 MB costs 4× per second at *any* deadline; the deadline only sets how many idle seconds you buy. That is the likeliest reason Java's example caps the tail at 90s, though it is inference rather than a documented rationale. Right-sizing beats it either way — the measured Worker used **240 MB of 1024**, so read `Max Memory Used` and cut. And `Init Duration` is billed, so a shorter deadline buys proportionally more billed inits. + +## Observability + +No extra dependency is required: `temporal-aws-lambda` already depends on `io.temporal:temporal-opentelemetry`, `io.opentelemetry:opentelemetry-api` (BOM 1.25.0), and `io.opentelemetry.contrib:opentelemetry-aws-xray`. The helper class ships inside the module. + +Import: `io.temporal.aws.lambda.OtelLambdaWorkerConfigurationHelper` + + + +- `configure(LambdaWorkerOptions.Builder)` — configures metrics and tracing with defaults. +- `configure(LambdaWorkerOptions.Builder, Consumer)` — same, with customization. +- `configureMetrics(LambdaWorkerOptions.Builder, OpenTelemetry)` — metrics only (an overload also takes a service name and a `Duration` report interval). +- `configureTracing(LambdaWorkerOptions.Builder, OpenTelemetry)` — tracing only. +- `configureFlushHook(LambdaWorkerOptions.Builder, OpenTelemetry, Duration)` — registers a flush before the invocation ends. + +Its own `newBuilder()` exposes `setOpenTelemetry`, `setEndpoint`, `setServiceName`, `setMetricsReportInterval`, `setFlushTimeout`, and `setFlushHook`. + +```java +LambdaWorker.define( + new WorkerDeploymentVersion("my-app", "build-1"), + builder -> { + builder.setTaskQueue("my-task-queue"); + builder.registerWorkflowImplementationTypes(MyWorkflowImpl.class); + builder.registerActivitiesImplementations(new MyActivitiesImpl()); + OtelLambdaWorkerConfigurationHelper.configure(builder); + }); +``` + +Defaults come from the constants `DEFAULT_OTLP_ENDPOINT` and `DEFAULT_SERVICE_NAME`, and the helper reads `OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_SERVICE_NAME`, and `AWS_LAMBDA_FUNCTION_NAME` from the environment. As with the other SDKs, the default endpoint is the ADOT layer's collector on `localhost:4317`. + +**Flush before the deadline.** A Serverless Worker's invocation ends on a deadline rather than after a request, so telemetry buffered past that point is lost. Use `configureFlushHook` (or a report interval shorter than the invocation deadline) so metrics and spans are exported before shutdown. This matters more on Java's shorter recommended deadline (90s) than on the 600s used elsewhere. + +Attach the ADOT Collector layer. Because the OpenTelemetry SDK arrives as an ordinary Maven dependency of `temporal-aws-lambda`, no language-specific auto-instrumentation layer is required for the Worker's own telemetry — the same situation as Go. + +`OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/otel-collector-config.yaml` — the `_URI` form, as with Go and TypeScript. The official Java sample packages `otel-collector-config.template.yaml` into the artifact root as `otel-collector-config.yaml` during `shadowJar`; with Maven, add it under `src/main/resources`. + +For the shared Collector configuration, X-Ray enablement, and execution-role permissions, see `observability.md`. + +## Diagnostic signatures + +| SDK | Cause | Fix | +|---|---|---| +| Java | The SDK compiles against `slf4j-api` **1.7.36**; a 2.x provider (`slf4j-simple:2.x`, Logback 1.3+) does not bind to a 1.7 API and nothing is emitted | use a 1.7.x provider, e.g. `org.slf4j:slf4j-simple:1.7.36` | + +**Java — `NullPointerException` in `ShutdownManager` on every invocation (benign).** As of `temporal-aws-lambda` 1.38.0, a normal graceful shutdown logs a `WARN` with a full stack trace: + +``` +[main] WARN io.temporal.internal.worker.ShutdownManager - Exception during waiting for termination +java.lang.NullPointerException: Cannot invoke "SuspendableWorker.awaitTermination(long, TimeUnit)" + because "this.workerCommandWorker" is null + at io.temporal.worker.WorkerFactory.lambda$awaitTermination$12(WorkerFactory.java:519) + at io.temporal.aws.lambda.DefaultLambdaWorkerRuntime$DefaultInvocation.awaitTermination(...:82) + at io.temporal.aws.lambda.LambdaWorker$Handler.shutdownInvocation(LambdaWorker.java:323) +``` + +This is **not** a failure. It appears *after* Tasks have completed, is followed by `Temporal Lambda worker stopped`, a clean `END`/`REPORT`, and no timeout; Workflows complete correctly. Do not change configuration, IAM, or timeouts in response to it. Confirm it is benign by checking that the Workflow completed and that `REPORT` shows a duration below the deadline, then ignore it. + +**Java — `ClassNotFoundException` / `NoClassDefFoundError` at first invocation.** The uber-jar was built without merging `META-INF/services`, or the handler string is wrong. Check the handler format first: Java uses `fully.qualified.Class::method`, not the `module.function` form every other SDK uses. Then verify the services merge — `unzip -p META-INF/services/io.grpc.ManagedChannelProvider` should list more than one provider. → Build and package above. + +**Java — exec-format or `UnsupportedClassVersionError` at first invocation.** Bytecode targets a newer JDK than the runtime. Set `` (or the Gradle toolchain) to match `--runtime`. diff --git a/references/aws-lambda/sdk-python.md b/references/aws-lambda/sdk-python.md new file mode 100644 index 0000000..583b1d2 --- /dev/null +++ b/references/aws-lambda/sdk-python.md @@ -0,0 +1,206 @@ +# Python SDK on AWS Lambda + + + +Use this reference for Python SDK-specific package, entry-point, Worker configuration, tuned defaults, observability, and diagnostic details. For shared AWS Lambda deployment, observability infrastructure, and diagnostic flow, see `setup.md`, `observability.md`, and `diagnostics.md`. + +## Package + +Import: `from temporalio.contrib.aws.lambda_worker import LambdaWorkerConfig, run_worker` + +Install: `pip install temporalio` — the contrib module ships inside the main package here (unlike Go and TypeScript, which need a separate dependency). Use `temporalio[lambda-worker-otel]` for OpenTelemetry support. + +- Python: [Python Lambda Worker sample](https://github.com/temporalio/samples-python/tree/main/lambda_worker) + +Read the installed API before generating code: + +```bash +python -c "import temporalio.contrib.aws.lambda_worker as m; help(m.LambdaWorkerConfig)" +``` + +**A useful ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs — Java's is `define`, not "run"-shaped like the others — so check rather than pattern-match from another language. + +**Fastest path:** start from the language sample linked above — it has a working Worker, Workflow, and Activity already wired together. The handler example below imports the Workflow and Activity from separate modules (`my_workflows`, `my_activities`). When writing from scratch, create those modules with at least one registered Workflow (declaring a versioning behavior) and one Activity, and name the entry-point file to match the `--handler` you deploy (for example, `lambda_function.py` → `--handler lambda_function.lambda_handler`). + +## Entry point + +`run_worker` — takes a `WorkerDeploymentVersion` and a configure callback, returns a Lambda handler. + +## Configure callback + +The `configure` callback receives a `LambdaWorkerConfig` dataclass with fields pre-populated with Lambda-appropriate defaults. Set the Task Queue, Workflows, and Activities through `worker_config`, which accepts the same keyword arguments as the `Worker` constructor. + +Go, Python and TypeScript invoke it per invocation. + +Python and TypeScript pass Workflow and Activity collections into the worker config. + +## Versioning behavior + +Set per-Workflow in the `@workflow.defn` decorator: `VersioningBehavior.PINNED` or `VersioningBehavior.AUTO_UPGRADE`. +Or set a Worker-level default with `default_versioning_behavior` in the worker config. + +**Worker Versioning is always on.** The run-worker entry point enables it, so the only remaining decision is `Pinned` vs `AutoUpgrade` per Workflow (or a Worker-level default). + +## Handler example + +Use the Python SDK's `lambda_worker` contrib package. + +```python +from temporalio.common import WorkerDeploymentVersion +from temporalio.contrib.aws.lambda_worker import LambdaWorkerConfig, run_worker + +from my_workflows import MyWorkflow +from my_activities import my_activity + + +def configure(config: LambdaWorkerConfig) -> None: + config.worker_config["task_queue"] = "my-task-queue" + config.worker_config["workflows"] = [MyWorkflow] + config.worker_config["activities"] = [my_activity] + + +lambda_handler = run_worker( + WorkerDeploymentVersion( + deployment_name="my-app", + build_id="build-1", + ), + configure, +) +``` + + +Versioning behavior: set per-Workflow in the `@workflow.defn` decorator with `VersioningBehavior.PINNED` or `VersioningBehavior.AUTO_UPGRADE`, or set a Worker-level default with `default_versioning_behavior` in the worker config. + +```python +from temporalio import workflow +from temporalio.common import VersioningBehavior + + +@workflow.defn(versioning_behavior=VersioningBehavior.PINNED) +class MyWorkflow: + @workflow.run + async def run(self, input: str) -> str: + ... +``` + + +## Lambda-tuned defaults + + + +| Setting | Lambda default | +|---|---| +| `max_concurrent_activities` | 2 | +| `max_concurrent_workflow_tasks` | 10 | +| `max_concurrent_local_activities` | 2 | +| `max_concurrent_nexus_tasks` | 5 | +| `workflow_task_poller_behavior` | `SimpleMaximum(2)` | +| `activity_task_poller_behavior` | `SimpleMaximum(1)` | +| `nexus_task_poller_behavior` | `SimpleMaximum(1)` | +| `graceful_shutdown_timeout` | 5 seconds | +| `max_cached_workflows` | 30 | +| `disable_eager_activity_execution` | Always `True` | +| `shutdown_deadline_buffer` | 7 seconds | + +`disable_eager_activity_execution` is always `True` and cannot be overridden. Eager Activities require a persistent connection, which Lambda invocations don't maintain. + +`shutdown_deadline_buffer` is specific to the `lambda_worker` package. It controls how much time before the Lambda deadline the Worker begins its graceful shutdown. The default is `graceful_shutdown_timeout` + 2 seconds. + +If your Worker handles long-running Activities, increase `graceful_shutdown_timeout`, `shutdown_deadline_buffer`, and the Lambda invocation deadline (`--timeout`) together. + +## Connection configuration + +The `lambda_worker` package automatically loads Temporal client configuration from a TOML config file and environment variables (see the Environment Configuration docs, `/develop/environment-configuration`). + +TOML config file resolution order: + +1. `TEMPORAL_CONFIG_FILE` environment variable, if set. +2. `temporal.toml` in `$LAMBDA_TASK_ROOT` (typically `/var/task`). +3. `temporal.toml` in the current working directory. + +The file is optional. If absent, only environment variables are used. + +## Build and package + +Install dependencies into a local directory for packaging, using `--platform` for Linux-compatible binaries: + +```bash +pip install --target ./package --platform manylinux2014_x86_64 --only-binary=:all: temporalio +``` + + +**Pin the download to the Lambda runtime's Python version and architecture, not your local interpreter's.** If they differ (e.g. local `3.14` vs the function's `python3.13`), add `--python-version 3.13` alongside `--only-binary=:all:` so pip fetches runtime-matching wheels, and keep `--platform` (`manylinux2014_x86_64` for `x86_64`, `manylinux2014_aarch64` for `arm64`) consistent with the function's `--architectures`. Mismatches surface as import errors only at invocation time, not at package time. + +To include OpenTelemetry support, install `temporalio[lambda-worker-otel]` instead. + +Package dependencies and application code: + +```bash +cd package && zip -r ../function.zip . && cd .. +zip function.zip lambda_function.py my_workflows.py my_activities.py +``` + + +## Deploy the Lambda function + +```bash +aws lambda create-function \ + --function-name my-temporal-worker \ + --runtime python3.13 \ + --handler lambda_function.lambda_handler \ + --role \ + --zip-file fileb://function.zip \ + --timeout 600 \ + --memory-size 256 \ + --environment '{"Variables":{"TEMPORAL_ADDRESS":":7233","TEMPORAL_NAMESPACE":"","TEMPORAL_API_KEY":""}}' +``` + + +- `--runtime`: `python3.13` (or another supported Python version). +- `--handler`: `lambda_function.lambda_handler` (entry point in `module.function` format, must point to the handler returned by `run_worker`). + +| SDK example | Memory | Full invocation | GB-seconds | +|---|---|---|---| +| Python 600s / 256 MB | 0.25 GB | ~594 s billed | ~149 | + +Measured cold starts are ~1s for Python and Java alike (`Init Duration` in the REPORT line). + +The `--environment` examples above pass `TEMPORAL_API_KEY` inline for brevity — **that is acceptable for development only.** For production, store the API key (or TLS private key) in AWS Secrets Manager or SSM Parameter Store, grant the *execution* role `secretsmanager:GetSecretValue` (or `ssm:GetParameter`), and load it at cold start before the Worker initializes — for example, at module scope in the handler file, fetch the secret and set `os.environ["TEMPORAL_API_KEY"]` so the serverless Worker package reads it at startup. Do not commit key values into the `--environment` block for production functions. + +## Observability + +Import: `from temporalio.contrib.aws.lambda_worker.otel import apply_defaults` + +To install with OTel support: `pip install temporalio[lambda-worker-otel]` + +- `apply_defaults` — configures both metrics and tracing. +- `build_metrics_telemetry_config` — configures metrics only. +- `apply_tracing` — configures tracing only. + +Usage in the configure callback: + +```python +def configure(config: LambdaWorkerConfig) -> None: + config.worker_config["task_queue"] = TASK_QUEUE + config.worker_config["workflows"] = [SampleWorkflow] + config.worker_config["activities"] = [hello_activity] + apply_defaults(config) +``` + +By default, telemetry is sent to `localhost:4317`, which is the ADOT Lambda layer's default collector endpoint. + +Attach the ADOT Python Lambda layer to your Lambda function. The layer includes both auto-instrumentation and an OpenTelemetry Collector that receives telemetry on `localhost:4317` and forwards traces to AWS X-Ray and metrics to Amazon CloudWatch. + +`OPENTELEMETRY_COLLECTOR_CONFIG_FILE=/var/task/otel-collector-config.yaml` + +Note: Python uses `_FILE` while Go and TypeScript use `_URI`. + +For Python, the `AWSXRayDaemonWriteAccess` managed policy can be attached instead. + +For the shared Collector configuration, X-Ray enablement, and execution-role permissions, see `observability.md`. + +## Diagnostic signatures + +| SDK | Cause | Fix | +|---|---|---| +| Python | `logging.basicConfig()` is a no-op when a root handler already exists, and the Lambda runtime installs one before your module is imported — so the level never changes and `INFO` records are filtered out | `logging.getLogger().setLevel(logging.INFO)` | diff --git a/references/aws-lambda/sdk-typescript.md b/references/aws-lambda/sdk-typescript.md new file mode 100644 index 0000000..603b1bb --- /dev/null +++ b/references/aws-lambda/sdk-typescript.md @@ -0,0 +1,201 @@ +# TypeScript SDK on AWS Lambda + + + +Use this reference for TypeScript SDK-specific package, entry-point, Worker configuration, tuned defaults, and observability details. For shared AWS Lambda deployment and observability infrastructure, see `setup.md` and `observability.md`. + +## Package + +Import: `import { runWorker } from '@temporalio/lambda-worker'` + +Install: `npm install @temporalio/lambda-worker` — a separate npm package from `@temporalio/worker`, versioned independently. + +- TypeScript: [TypeScript Lambda Worker sample](https://github.com/temporalio/samples-typescript/tree/main/lambda-worker) + +Check the installed version, then read its type declarations: + +```bash +npm ls @temporalio/lambda-worker +``` + +**A useful ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs — Java's is `define`, not "run"-shaped like the others — so check rather than pattern-match from another language. + +## Entry point + +`runWorker` — creates a Lambda handler that runs a Temporal Worker. Pass a deployment version and a configure callback. + +## Configure callback + +Set Worker options via `config.workerOptions`. For Workflow code, use `workflowBundle` with pre-bundled code instead of `workflowsPath` to avoid webpack bundling overhead on Lambda cold starts. + +Go, Python and TypeScript invoke it per invocation. + +Python and TypeScript pass Workflow and Activity collections into the worker config. + +## Pre-bundling Workflow code + +Build the bundle as a separate build step: + +```typescript +import { bundleWorkflowCode } from '@temporalio/worker'; +import { writeFile } from 'fs/promises'; + +const { code } = await bundleWorkflowCode({ + workflowsPath: require.resolve('./workflows'), +}); +await writeFile('./workflow-bundle.js', code); +``` + + +Then reference the bundle in your handler with `workflowBundle: { codePath: require.resolve('./workflow-bundle.js') }`. + +## Versioning behavior + +Set per-Workflow with `setWorkflowOptions` in the Workflow file, or set a default for all Workflows with `defaultVersioningBehavior` in the configure callback. +Values are `'PINNED'` or `'AUTO_UPGRADE'`. The default versioning behavior is `PINNED`. + +Access via: `config.workerOptions.workerDeploymentOptions!.defaultVersioningBehavior = 'PINNED'` + +**Worker Versioning is always on.** The run-worker entry point enables it, so the only remaining decision is `Pinned` vs `AutoUpgrade` per Workflow (or a Worker-level default). + +## Handler example + +Use the `@temporalio/lambda-worker` package. + +```typescript +import { runWorker } from '@temporalio/lambda-worker'; +import * as activities from './activities'; + +export const handler = runWorker({ deploymentName: 'my-app', buildId: 'build-1' }, (config) => { + config.workerOptions.taskQueue = 'my-task-queue'; + config.workerOptions.workflowBundle = { + codePath: require.resolve('./workflow-bundle.js'), + }; + config.workerOptions.activities = activities; + config.workerOptions.workerDeploymentOptions!.defaultVersioningBehavior = 'PINNED'; +}); +``` + + +Use `workflowBundle` with pre-bundled code instead of `workflowsPath` to avoid webpack bundling overhead on Lambda cold starts. + +Versioning behavior: set per-Workflow with `setWorkflowOptions` in the Workflow file, or set a default for all Workflows with `defaultVersioningBehavior` in the configure callback. Values are `'AUTO_UPGRADE'` or `'PINNED'`. + +## Lambda-tuned defaults + + + +| Setting | Lambda default | +|---|---| +| `maxConcurrentActivityTaskExecutions` | 2 | +| `maxConcurrentWorkflowTaskExecutions` | 10 | +| `maxConcurrentLocalActivityExecutions` | 2 | +| `maxConcurrentNexusTaskExecutions` | 5 | +| `workflowTaskPollerBehavior` | `SimpleMaximum(2)` | +| `activityTaskPollerBehavior` | `SimpleMaximum(1)` | +| `nexusTaskPollerBehavior` | `SimpleMaximum(1)` | +| `shutdownGraceTime` | 5 seconds | +| `maxCachedWorkflows` | 30 | +| `shutdownDeadlineBufferMs` | 7000 | + +Eager Activities are not supported. Lambda invocations don't maintain persistent connections. + +`shutdownDeadlineBufferMs` is specific to the `@temporalio/lambda-worker` package. It controls how much time before the Lambda deadline the Worker begins its graceful shutdown. The default is `shutdownGraceTime` (5s) + 2s. + +If your Worker handles long-running Activities, increase `shutdownGraceTime`, `shutdownDeadlineBufferMs`, and the Lambda invocation deadline (`--timeout`) together. + +## Connection configuration + +The `@temporalio/lambda-worker` package automatically loads Temporal client configuration from a TOML config file and environment variables (see the Environment Configuration docs, `/develop/environment-configuration`). + +TOML config file resolution order: + +1. `TEMPORAL_CONFIG_FILE` environment variable, if set. +2. `temporal.toml` in `$LAMBDA_TASK_ROOT` (typically `/var/task`). +3. `temporal.toml` in the current working directory. + +The file is optional. If absent, only environment variables are used. + +## Build and package + +Build the Workflow bundle and compile the project: + +```bash +npx ts-node src/scripts/build-workflow-bundle.ts +npx tsc +``` + + +Install production dependencies and package everything: + +```bash +npm install --omit=dev +zip -r function.zip lib/ node_modules/ workflow-bundle.js +``` + + +## Deploy the Lambda function + +```bash +aws lambda create-function \ + --function-name my-temporal-worker \ + --runtime nodejs22.x \ + --handler lib/index.handler \ + --role \ + --zip-file fileb://function.zip \ + --timeout 600 \ + --memory-size 256 \ + --environment '{"Variables":{"HOME":"/tmp","TEMPORAL_ADDRESS":":7233","TEMPORAL_NAMESPACE":"","TEMPORAL_API_KEY":""}}' +``` + + +- `--runtime`: `nodejs22.x` (or another supported Node.js version, 20+). +- `--handler`: `lib/index.handler` (entry point in `module.export` format, must point to the handler exported by `runWorker`). + +| Variable | Description | +|---|---| +| `HOME` | Set to `/tmp` in the Go and TypeScript examples above. Lambda's filesystem is read-only outside `/tmp`, so anything the runtime or config loader resolves relative to the home directory needs a writable target. The docs omit it from the Python example; including it there is harmless. | + +## Observability + +Import: `import { applyDefaults } from '@temporalio/lambda-worker/otel'` + +- `applyDefaults` — registers Temporal SDK interceptors for tracing and configures the Core SDK to export metrics via OTLP. +- `makeOtelPlugin` — returns a plugin for pre-bundling Workflow code that includes Workflow interceptor modules. + +Usage in the configure callback: + +```typescript +export const handler = runWorker({ deploymentName: 'sdk-demo', buildId: 'v1' }, (config) => { + config.workerOptions.taskQueue = TASK_QUEUE; + config.workerOptions.workflowBundle = { + codePath: require.resolve('./workflow-bundle.js'), + }; + config.workerOptions.activities = activities; + applyDefaults(config); +}); +``` + +When pre-bundling Workflow code, pass the plugin from `makeOtelPlugin()` so that Workflow interceptor modules are included in the bundle: + +```typescript +import { bundleWorkflowCode } from '@temporalio/worker'; +import { makeOtelPlugin } from '@temporalio/lambda-worker/otel'; + +const { plugin } = makeOtelPlugin(); +const { code } = await bundleWorkflowCode({ + workflowsPath: require.resolve('./workflows'), + plugins: [plugin], +}); +``` + +By default, telemetry is sent to `localhost:4317`, which is the ADOT Lambda layer's default collector endpoint. + +Attach two ADOT Lambda layers: + +1. The ADOT JavaScript layer for Node.js-side auto-instrumentation and trace export. +2. The ADOT Collector layer (`aws-otel-collector-amd64`) to run the OTel Collector as a Lambda extension, receiving telemetry via OTLP on `localhost:4317` and forwarding traces to X-Ray and metrics to CloudWatch. + +`OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/otel-collector-config.yaml` + +For the shared Collector configuration, X-Ray enablement, and execution-role permissions, see `observability.md`. diff --git a/references/aws-lambda/setup.md b/references/aws-lambda/setup.md index fd04b01..6fbb102 100644 --- a/references/aws-lambda/setup.md +++ b/references/aws-lambda/setup.md @@ -19,11 +19,7 @@ This is the end-to-end golden path: connect, write the Worker, package and deplo - The Go SDK, Python SDK, TypeScript SDK, or Java SDK, depending on your language. - The `temporal` CLI, authenticated to the target Temporal Service — Steps 4–6 and the CLI troubleshooting paths use it. See "Temporal CLI and Cloud connection" below. -Sample projects: -- Go: [Go Lambda Worker sample](https://github.com/temporalio/samples-go/tree/main/lambda-worker) -- Python: [Python Lambda Worker sample](https://github.com/temporalio/samples-python/tree/main/lambda_worker) -- TypeScript: [TypeScript Lambda Worker sample](https://github.com/temporalio/samples-typescript/tree/main/lambda-worker) -- Java: [Java Lambda Worker sample](https://github.com/temporalio/samples-java/tree/main/lambda-worker) — three Gradle subprojects (`worker/` handler + greeting Workflow/Activity, `starter/` local client, `deploy/` IAM and deploy scripts plus a CloudFormation template) +The selected SDK reference links its maintained sample project. ## Temporal CLI and Cloud connection @@ -119,331 +115,24 @@ Do not proceed to Steps 4–6 on the assumption auth will work — re-run this c The Worker handles the per-invocation lifecycle: connecting to Temporal, polling for tasks, and gracefully shutting down before the invocation deadline. -### Install the serverless Worker package first +Load the reference for the selected SDK alongside this shared deployment guide: -**The serverless Worker package is not always part of the main SDK.** Install it explicitly before writing code — do not assume an `import` resolves just because the base SDK is present. Scaffolding a project and discovering only at build time that the package lives in its own module means backing out and redoing the module setup. - -| SDK | Install | Packaging | -|---|---|---| -| Go | `go get go.temporal.io/sdk/contrib/aws/lambdaworker` | **Separate Go module** from `go.temporal.io/sdk`, with its own version line (`v0.1.1` at the time of writing). It is *not* pulled in by the main SDK — `go get` it directly, then `go mod tidy`. | -| Python | `pip install temporalio` | `temporalio.contrib.aws.lambda_worker` ships inside the main `temporalio` package. Use `temporalio[lambda-worker-otel]` to add OpenTelemetry. | -| TypeScript | `npm install @temporalio/lambda-worker` | Separate npm package from `@temporalio/worker`, versioned independently. | -| Java | `io.temporal:temporal-aws-lambda` (Maven/Gradle) | **Separate artifact** from `io.temporal:temporal-sdk`, but on the **same version line** (both 1.38.0). Import `io.temporal:temporal-bom` in `dependencyManagement` to keep them aligned. `aws-lambda-java-core` 1.4.0 comes transitively. | - -### Verify the installed API before generating code - -These are Public Preview APIs and signatures drift between versions. Read the real surface of the version you just installed rather than writing from memory — a wrong field name costs a build cycle: - -```bash -# Go — list the exported API of the installed module version -go doc go.temporal.io/sdk/contrib/aws/lambdaworker -go doc go.temporal.io/sdk/contrib/aws/lambdaworker.Options - -# Python -python -c "import temporalio.contrib.aws.lambda_worker as m; help(m.LambdaWorkerConfig)" - -# TypeScript — check the installed version, then read its type declarations -npm ls @temporalio/lambda-worker - -# Java — list the real public API of the resolved artifact -javap -cp ~/.m2/repository/io/temporal/temporal-aws-lambda//temporal-aws-lambda-.jar \ - io.temporal.aws.lambda.LambdaWorker -javap -cp 'io.temporal.aws.lambda.LambdaWorkerOptions$Builder' -# or read the source directly — Maven Central publishes a sources jar: -# curl -O https://repo1.maven.org/maven2/io/temporal/temporal-aws-lambda//temporal-aws-lambda--sources.jar -``` - -**A useful ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs — Java's is `define`, not "run"-shaped like the others — so check rather than pattern-match from another language. +| SDK | Reference | +|---|---| +| Go | `sdk-go.md` | +| Python | `sdk-python.md` | +| TypeScript | `sdk-typescript.md` | +| Java | `sdk-java.md` | -Specifics worth confirming this way, because they differ by SDK and are easy to get wrong from memory: +Complete the selected SDK reference before continuing. -- **Where the Task Queue lives.** In Go it is a direct field on the options object (`opts.TaskQueue`). In Python it goes through the worker-config mapping (`config.worker_config["task_queue"]`), in TypeScript through worker options (`config.workerOptions.taskQueue`), and in Java through a builder setter (`builder.setTaskQueue(...)`). Do not carry one shape over to another language. -- **When the configure callback runs.** Go, Python and TypeScript invoke it per invocation. **Java invokes it once, at cold start**, and offers a separate `LambdaWorker.InvocationConfigurator` for per-invocation work. Putting per-invocation logic in Java's cold-start callback silently runs it once for the life of the container. -- **Where registration happens.** In Go the `Register*` methods hang off the same options object; Python and TypeScript pass Workflow and Activity collections into the worker config. - **You do not construct a client.** Connection details (address, namespace, API key) load automatically from the process environment, so `TEMPORAL_*` variables set on the function flow straight through with no client code. In a Lambda that means the `--environment` block at deploy time: no config file is bundled unless you put one there, and the operator's own CLI configuration never reaches the function (see "Operator CLI config does not reach the function" below). -- **Worker Versioning is always on.** The run-worker entry point enables it, so the only remaining decision is `Pinned` vs `AutoUpgrade` per Workflow (or a Worker-level default). - -**Fastest path:** start from the language sample linked in Prerequisites — it has a working Worker, Workflow, and Activity already wired together. The handler examples below import the Workflow and Activity from separate modules (`my_workflows`, `my_activities`). When writing from scratch, create those modules with at least one registered Workflow (declaring a versioning behavior) and one Activity, and name the entry-point file to match the `--handler` you deploy (for example, `lambda_function.py` → `--handler lambda_function.lambda_handler`). - -### Go - -Use the Go SDK's `lambdaworker` package. - -```go -package main - -import ( - lambdaworker "go.temporal.io/sdk/contrib/aws/lambdaworker" - "go.temporal.io/sdk/worker" - "go.temporal.io/sdk/workflow" -) - -func main() { - lambdaworker.RunWorker(worker.WorkerDeploymentVersion{ - DeploymentName: "my-app", - BuildID: "build-1", - }, func(opts *lambdaworker.Options) error { - opts.TaskQueue = "my-task-queue" - - opts.RegisterWorkflowWithOptions(MyWorkflow, workflow.RegisterOptions{ - VersioningBehavior: workflow.VersioningBehaviorPinned, - }) - opts.RegisterActivity(MyActivity) - - return nil - }) -} -``` - - -Versioning behavior: set per-Workflow at registration time with `workflow.VersioningBehaviorPinned` or `workflow.VersioningBehaviorAutoUpgrade`, or set a Worker-level default with `DefaultVersioningBehavior` in `DeploymentOptions`. - -### Python - -Use the Python SDK's `lambda_worker` contrib package. - -```python -from temporalio.common import WorkerDeploymentVersion -from temporalio.contrib.aws.lambda_worker import LambdaWorkerConfig, run_worker - -from my_workflows import MyWorkflow -from my_activities import my_activity - - -def configure(config: LambdaWorkerConfig) -> None: - config.worker_config["task_queue"] = "my-task-queue" - config.worker_config["workflows"] = [MyWorkflow] - config.worker_config["activities"] = [my_activity] - - -lambda_handler = run_worker( - WorkerDeploymentVersion( - deployment_name="my-app", - build_id="build-1", - ), - configure, -) -``` - - -Versioning behavior: set per-Workflow in the `@workflow.defn` decorator with `VersioningBehavior.PINNED` or `VersioningBehavior.AUTO_UPGRADE`, or set a Worker-level default with `default_versioning_behavior` in the worker config. - -```python -from temporalio import workflow -from temporalio.common import VersioningBehavior - - -@workflow.defn(versioning_behavior=VersioningBehavior.PINNED) -class MyWorkflow: - @workflow.run - async def run(self, input: str) -> str: - ... -``` - - -### TypeScript - -Use the `@temporalio/lambda-worker` package. - -```typescript -import { runWorker } from '@temporalio/lambda-worker'; -import * as activities from './activities'; - -export const handler = runWorker({ deploymentName: 'my-app', buildId: 'build-1' }, (config) => { - config.workerOptions.taskQueue = 'my-task-queue'; - config.workerOptions.workflowBundle = { - codePath: require.resolve('./workflow-bundle.js'), - }; - config.workerOptions.activities = activities; - config.workerOptions.workerDeploymentOptions!.defaultVersioningBehavior = 'PINNED'; -}); -``` - - -Use `workflowBundle` with pre-bundled code instead of `workflowsPath` to avoid webpack bundling overhead on Lambda cold starts. - -Versioning behavior: set per-Workflow with `setWorkflowOptions` in the Workflow file, or set a default for all Workflows with `defaultVersioningBehavior` in the configure callback. Values are `'AUTO_UPGRADE'` or `'PINNED'`. - -### Java - -Use the `temporal-aws-lambda` module. The handler class implements `RequestHandler` and delegates to the handler returned by `LambdaWorker.define`. - -```java -package com.example.temporal; - -import com.amazonaws.services.lambda.runtime.Context; -import com.amazonaws.services.lambda.runtime.RequestHandler; -import io.temporal.aws.lambda.LambdaWorker; -import io.temporal.common.WorkerDeploymentVersion; - -public final class LambdaFunction implements RequestHandler { - - // The callback below runs ONCE, at cold start, when the handler is constructed -- - // not per invocation. Use the 3-arg define(...) overload with an - // InvocationConfigurator for anything that must run per invocation. - private static final RequestHandler WORKER = - LambdaWorker.define( - new WorkerDeploymentVersion("my-app", "build-1"), - builder -> { - builder.setTaskQueue("my-task-queue"); - builder.registerWorkflowImplementationTypes(MyWorkflowImpl.class); - builder.registerActivitiesImplementations(new MyActivitiesImpl()); - }); - - @Override - public Void handleRequest(Object input, Context context) { - return WORKER.handleRequest(input, context); - } -} -``` - -The entry point is `define` (or `newHandler` for pre-built options) — not a "run"-shaped name like the other SDKs use. Temporal's [sample handler](https://github.com/temporalio/samples-java/blob/main/lambda-worker/worker/src/main/java/io/temporal/samples/lambdaworker/LambdaFunction.java) is the reference implementation. - -Versioning behavior: annotate the Workflow **method** in the implementation class with `io.temporal.workflow.WorkflowVersioningBehavior`, or set a Worker-level default with `DefaultVersioningBehavior` in `DeploymentOptions`. - -```java -public class MyWorkflowImpl implements MyWorkflow { - @Override - @WorkflowVersioningBehavior(VersioningBehavior.PINNED) - public String getGreeting(String name) { ... } -} -``` - -**Logging needs an SLF4J 1.7.x provider.** The SDK compiles against `slf4j-api:1.7.36`; a 2.x provider will not bind and the Worker produces no logs. Add `org.slf4j:slf4j-simple:1.7.36`. With it, the module logs `Temporal Lambda worker started … taskQueue=… identity=…` unprompted. → `sdk-configuration.md` (Java SDK). ## Step 2: Deploy Lambda function ### Build and package -#### Go - -Cross-compile for Lambda's Linux runtime: - -```bash -GOOS=linux GOARCH=amd64 go build -tags lambda.norpc -o bootstrap ./worker -``` - - -Package the binary into a zip file: - -```bash -zip function.zip bootstrap -``` - - -**Add `CGO_ENABLED=0`, and match the architecture you deploy.** The `provided.al2023` runtime expects a self-contained binary; building with cgo enabled links against host libraries that may not resolve inside the runtime. Set `CGO_ENABLED=0` for a statically linked binary, and keep `GOARCH` consistent with the function's `--architectures` (`amd64` ↔ `x86_64`, `arm64` ↔ `arm64`). Also adjust the trailing package path to your layout — `.` when `main` is in the repo root, `./worker` when it is in a `worker/` subdirectory. A reusable script: - -```bash -#!/usr/bin/env bash -set -euo pipefail -go vet ./... # catches a missing import before the cross-compile -CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -tags lambda.norpc -o bootstrap . -zip -q function.zip bootstrap -file bootstrap # expect: ELF 64-bit ... statically linked -``` - -Run `go vet` (or a plain `go build ./...`) before the packaging build. The three-package import block above — `lambdaworker`, `worker` for `WorkerDeploymentVersion`, and `workflow` for the versioning-behavior constants — is easy to write short by one entry, and catching that locally is faster than discovering it in the cross-compile step. - -An architecture mismatch surfaces only at invocation time as an `Runtime.InvalidEntrypoint`/exec-format error, not at build or package time — the same failure class as the Python wheel mismatch below. - -A typical Go Worker zip lands around 10–15 MB, well under the 50 MB direct-upload limit. - -#### Python - -Install dependencies into a local directory for packaging, using `--platform` for Linux-compatible binaries: - -```bash -pip install --target ./package --platform manylinux2014_x86_64 --only-binary=:all: temporalio -``` - - -**Pin the download to the Lambda runtime's Python version and architecture, not your local interpreter's.** If they differ (e.g. local `3.14` vs the function's `python3.13`), add `--python-version 3.13` alongside `--only-binary=:all:` so pip fetches runtime-matching wheels, and keep `--platform` (`manylinux2014_x86_64` for `x86_64`, `manylinux2014_aarch64` for `arm64`) consistent with the function's `--architectures`. Mismatches surface as import errors only at invocation time, not at package time. - -To include OpenTelemetry support, install `temporalio[lambda-worker-otel]` instead. - -Package dependencies and application code: - -```bash -cd package && zip -r ../function.zip . && cd .. -zip function.zip lambda_function.py my_workflows.py my_activities.py -``` - - -#### TypeScript - -Build the Workflow bundle and compile the project: - -```bash -npx ts-node src/scripts/build-workflow-bundle.ts -npx tsc -``` - - -Install production dependencies and package everything: - -```bash -npm install --omit=dev -zip -r function.zip lib/ node_modules/ workflow-bundle.js -``` - - -#### Java - -Build an uber-jar with all dependencies bundled. A JAR is a valid zip, so it uploads directly with no extra packaging step. - -**Gradle** (what the official sample uses): `./gradlew shadowJar` → `build/libs/-all.jar`. - -**Maven**: `maven-shade-plugin`, bound to `package` → `target/.jar`. - -```xml - - org.apache.maven.plugins - maven-shade-plugin - 3.6.0 - - - package - shade - - false - - - - - - *:* - - META-INF/*.SF - META-INF/*.DSA - META-INF/*.RSA - module-info.class - - - - - - - -``` - -**`ServicesResourceTransformer` is mandatory, not hygiene.** The Temporal client is gRPC-based, and gRPC discovers channel providers, name resolvers, and load balancers through `META-INF/services` files that several jars each contribute to. Without merging, later copies overwrite earlier ones and the client fails at the **first invocation** with a "no functional channel service provider found"-class error — never at build time. Verify the merge before uploading: - -```bash -unzip -p target/.jar META-INF/services/io.grpc.ManagedChannelProvider -# expect MORE THAN ONE provider line, e.g.: -# io.grpc.netty.shaded.io.grpc.netty.NettyChannelProvider -# io.grpc.netty.shaded.io.grpc.netty.UdsNettyChannelProvider -``` - -Excluding the signature files matters too: signed-jar signatures are invalid inside an uber-jar and produce a `SecurityException` at class load. - -**Match the bytecode target to the runtime.** Compiling on a newer JDK than the function's runtime needs an explicit target — `17` for `--runtime java17`. This is the Java form of the architecture/wheel mismatch: it fails at invocation, not at build. - -**Watch the artifact size — Java hits the 50 MB direct-upload ceiling early.** A hello-world Worker (one Workflow, one Activity, `slf4j-simple`) measured **41 MB**, versus ~14 MB for the equivalent Python package and 10–15 MB for Go. Anything with real dependencies will exceed 50 MB and must be uploaded via S3 (`--code S3Bucket=…,S3Key=…`) rather than `--zip-file fileb://`. Check before deploying: - -```bash -ls -lh target/.jar -``` +See the selected SDK reference's **Build and package** section. ### Deploy the Lambda function @@ -463,7 +152,7 @@ ls -lh target/.jar ```bash cat > /tmp/lambda-env.json < \ - --zip-file fileb://function.zip \ - --timeout 600 \ - --memory-size 256 \ - --environment '{"Variables":{"HOME":"/tmp","TEMPORAL_ADDRESS":":7233","TEMPORAL_NAMESPACE":"","TEMPORAL_API_KEY":""}}' -``` - - -- `--runtime`: `provided.al2023` for custom Go binaries. -- `--handler`: `bootstrap` when using the `provided.al2023` custom runtime. - -#### Python - -```bash -aws lambda create-function \ - --function-name my-temporal-worker \ - --runtime python3.13 \ - --handler lambda_function.lambda_handler \ - --role \ - --zip-file fileb://function.zip \ - --timeout 600 \ - --memory-size 256 \ - --environment '{"Variables":{"TEMPORAL_ADDRESS":":7233","TEMPORAL_NAMESPACE":"","TEMPORAL_API_KEY":""}}' -``` - - -- `--runtime`: `python3.13` (or another supported Python version). -- `--handler`: `lambda_function.lambda_handler` (entry point in `module.function` format, must point to the handler returned by `run_worker`). - -#### TypeScript - -```bash -aws lambda create-function \ - --function-name my-temporal-worker \ - --runtime nodejs22.x \ - --handler lib/index.handler \ - --role \ - --zip-file fileb://function.zip \ - --timeout 600 \ - --memory-size 256 \ - --environment '{"Variables":{"HOME":"/tmp","TEMPORAL_ADDRESS":":7233","TEMPORAL_NAMESPACE":"","TEMPORAL_API_KEY":""}}' -``` - - -- `--runtime`: `nodejs22.x` (or another supported Node.js version, 20+). -- `--handler`: `lib/index.handler` (entry point in `module.export` format, must point to the handler exported by `runWorker`). - -#### Java - -```bash -aws lambda create-function \ - --function-name my-temporal-worker \ - --runtime java17 \ - --architectures x86_64 \ - --handler com.example.temporal.LambdaFunction::handleRequest \ - --role \ - --zip-file fileb://target/my-worker.jar \ - --timeout 90 \ - --memory-size 1024 \ - --environment file:///tmp/lambda-env.json -``` - -- `--runtime`: `java17` (or another supported Java version). -- `--handler`: `fully.qualified.Class::method` — **a different format from every other SDK**, which use `module.function` / `module.export`. Point it at the method that delegates to the `LambdaWorker.define` handler. -- `--zip-file`: the shaded jar directly; no separate zip step. Switch to `--code S3Bucket=…,S3Key=…` once the jar exceeds 50 MB, which happens early in Java (see packaging above). -- **`HOME=/tmp` is not needed** — unlike the Go and TypeScript examples. Verified: the Java module never reads `HOME`, and a missing config file is non-fatal. → `sdk-configuration.md` (Java SDK, Connection configuration). -- `--memory-size`: the docs recommend starting at `1024` because "Java Workers typically need more memory than other runtimes," then adjusting from CloudWatch. A measured hello-world used **240 MB of 1024** (`Max Memory Used` in the invocation's REPORT line), so `512` is usually ample for small Workers — and since Lambda bills GB-seconds, halving memory halves the bill. Start at 1024, read the metric, then cut. - - +Run the selected SDK reference's deployment command before continuing. ### Wait for the function to become Active @@ -579,22 +193,13 @@ aws lambda get-function --function-name my-temporal-worker \ **Caution:** AWS Lambda functions default to a 3-second timeout, which is too short for the Worker to start, connect to Temporal, and register the Task Queue. If the first invocation times out before the Worker polls, the Task Queue binding is never created and the Lambda is never invoked again. Always set `--timeout` high enough for the Worker to start, process Tasks, and shut down gracefully. -**`--timeout` is a cost setting once it clears startup.** The per-SDK examples differ deliberately — 600 for Go, Python and TypeScript; 90 for Java — and both clear startup easily: a measured Java Worker bound its Task Queue **~10s** after `create-version`, JVM cold start included, against the 83s of polling a 90s deadline allows. Lambda's 3-second default is what fails this; 90 does not. - Set it from three constraints: -1. **> cold start + connect + Task Queue registration.** The binding requirement, and what rules out the 3s default. Measured cold starts are ~1s for Python and Java alike (`Init Duration` in the REPORT line). +1. **> cold start + connect + Task Queue registration.** The binding requirement, and what rules out the 3s default. 2. **> longest Activity + shutdown deadline buffer.** An Activity still running when the Worker drains is abandoned and retried. 3. **Beyond those, pure cost.** Longer: fewer invocations and cold starts, warmer sticky cache, room for longer Activities. Shorter: a smaller idle tail — when work stops the Worker polls on until its deadline, so the waste is one deadline's worth. -Lambda bills **GB-seconds** — allocated memory × billed duration, however idle the Worker was: - -| SDK example | Memory | Full invocation | GB-seconds | -|---|---|---|---| -| Python 600s / 256 MB | 0.25 GB | ~594 s billed | ~149 | -| Java 90s / 1024 MB | 1 GB | ~84 s billed | ~84 | - -**Memory is the multiplier, not the deadline.** 1024 MB costs 4× per second at *any* deadline; the deadline only sets how many idle seconds you buy. That is the likeliest reason Java's example caps the tail at 90s, though it is inference rather than a documented rationale. Right-sizing beats it either way — the measured Worker used **240 MB of 1024**, so read `Max Memory Used` and cut. And `Init Duration` is billed, so a shorter deadline buys proportionally more billed inits. +Lambda bills **GB-seconds** — allocated memory × billed duration, however idle the Worker was. ### Environment variables @@ -602,7 +207,6 @@ Lambda bills **GB-seconds** — allocated memory × billed duration, however idl | Variable | Description | |---|---| -| `HOME` | Set to `/tmp` in the Go and TypeScript examples above. Lambda's filesystem is read-only outside `/tmp`, so anything the runtime or config loader resolves relative to the home directory needs a writable target. The docs omit it from the Python example; including it there is harmless. | | `TEMPORAL_ADDRESS` | Temporal frontend address (e.g., `..tmprl.cloud:7233`). | | `TEMPORAL_NAMESPACE` | Temporal Namespace. For Temporal Cloud, the fully-qualified `.`, not the bare name. | | `TEMPORAL_TASK_QUEUE` | Task Queue name. Overrides the value set in code. | @@ -614,8 +218,6 @@ The serverless Worker packages read environment variables and configuration file Sensitive values like TLS keys and API keys should be encrypted at rest. -The `--environment` examples above pass `TEMPORAL_API_KEY` inline for brevity — **that is acceptable for development only.** For production, store the API key (or TLS private key) in AWS Secrets Manager or SSM Parameter Store, grant the *execution* role `secretsmanager:GetSecretValue` (or `ssm:GetParameter`), and load it at cold start before the Worker initializes — for example, at module scope in the handler file, fetch the secret and set `os.environ["TEMPORAL_API_KEY"]` so the serverless Worker package reads it at startup. Do not commit key values into the `--environment` block for production functions. - For updating the function code and publishing immutable versions, see `versioning.md`. ## Step 3: Configure IAM for Temporal invocation diff --git a/references/sdk-configuration.md b/references/sdk-configuration.md deleted file mode 100644 index 3ebe97b..0000000 --- a/references/sdk-configuration.md +++ /dev/null @@ -1,331 +0,0 @@ -# SDK Configuration for Serverless Workers - - - -## Go SDK - -### Package - -Import: `lambdaworker "go.temporal.io/sdk/contrib/aws/lambdaworker"` - -Install: `go get go.temporal.io/sdk/contrib/aws/lambdaworker` — **this is a separate Go module** from `go.temporal.io/sdk`, versioned independently (`v0.1.1` at the time of writing). Having the main SDK in `go.mod` does not make it importable; add it explicitly, then `go mod tidy`. Verify the installed surface with `go doc go.temporal.io/sdk/contrib/aws/lambdaworker` before generating code — the API is Public Preview and drifts. - -### Entry point - -`lambdaworker.RunWorker` — starts a Lambda-based Worker. Pass a `WorkerDeploymentVersion` and a callback that registers Workflows and Activities. - -### Configure callback - -The `Options` callback gives access to the same registration methods as a traditional Worker: `RegisterWorkflow`, `RegisterWorkflowWithOptions`, `RegisterActivity`, `RegisterActivityWithOptions`, and `RegisterNexusService`. - -### Versioning behavior - -Set per-Workflow at registration time with `workflow.VersioningBehaviorPinned` or `workflow.VersioningBehaviorAutoUpgrade`. -Or set a Worker-level default with `DefaultVersioningBehavior` in `DeploymentOptions`. - -### Lambda-tuned defaults - - - -| Setting | Lambda default | -|---|---| -| `MaxConcurrentActivityExecutionSize` | 2 | -| `MaxConcurrentWorkflowTaskExecutionSize` | 10 | -| `MaxConcurrentLocalActivityExecutionSize` | 2 | -| `MaxConcurrentNexusTaskExecutionSize` | 5 | -| `MaxConcurrentActivityTaskPollers` | 1 | -| `MaxConcurrentWorkflowTaskPollers` | 2 | -| `MaxConcurrentNexusTaskPollers` | 1 | -| `WorkerStopTimeout` | 5 seconds | -| `DisableEagerActivities` | Always true | -| Sticky cache size | 100 | -| `ShutdownDeadlineBuffer` | 7 seconds | - -These are the same `worker.Options` available to any Temporal Worker, just with lower values for Lambda's constrained environment. Except for `ShutdownDeadlineBuffer`, which is specific to the `lambdaworker` package. - -`DisableEagerActivities` is always true and cannot be overridden. Eager Activities require a persistent connection, which Lambda invocations don't maintain. - -`ShutdownDeadlineBuffer` controls how much time before the Lambda deadline the Worker begins its graceful shutdown. The default is `WorkerStopTimeout` + 2 seconds. - -If your Worker handles long-running Activities, increase `WorkerStopTimeout`, `ShutdownDeadlineBuffer`, and the Lambda invocation deadline (`--timeout`) together. - -### Connection configuration - -The `lambdaworker` package automatically loads Temporal client configuration from a TOML config file and environment variables (see the Environment Configuration docs, `/develop/environment-configuration`). - -TOML config file resolution order: - -1. `TEMPORAL_CONFIG_FILE` environment variable, if set. -2. `temporal.toml` in `$LAMBDA_TASK_ROOT` (typically `/var/task`). -3. `temporal.toml` in the current working directory. - -The file is optional. If absent, only environment variables are used. - ---- - -## Python SDK - -### Package - -Import: `from temporalio.contrib.aws.lambda_worker import LambdaWorkerConfig, run_worker` - -Install: `pip install temporalio` — the contrib module ships inside the main package here (unlike Go and TypeScript, which need a separate dependency). Use `temporalio[lambda-worker-otel]` for OpenTelemetry support. - -### Entry point - -`run_worker` — takes a `WorkerDeploymentVersion` and a configure callback, returns a Lambda handler. - -### Configure callback - -The `configure` callback receives a `LambdaWorkerConfig` dataclass with fields pre-populated with Lambda-appropriate defaults. Set the Task Queue, Workflows, and Activities through `worker_config`, which accepts the same keyword arguments as the `Worker` constructor. - -### Versioning behavior - -Set per-Workflow in the `@workflow.defn` decorator: `VersioningBehavior.PINNED` or `VersioningBehavior.AUTO_UPGRADE`. -Or set a Worker-level default with `default_versioning_behavior` in the worker config. - -### Lambda-tuned defaults - - - -| Setting | Lambda default | -|---|---| -| `max_concurrent_activities` | 2 | -| `max_concurrent_workflow_tasks` | 10 | -| `max_concurrent_local_activities` | 2 | -| `max_concurrent_nexus_tasks` | 5 | -| `workflow_task_poller_behavior` | `SimpleMaximum(2)` | -| `activity_task_poller_behavior` | `SimpleMaximum(1)` | -| `nexus_task_poller_behavior` | `SimpleMaximum(1)` | -| `graceful_shutdown_timeout` | 5 seconds | -| `max_cached_workflows` | 30 | -| `disable_eager_activity_execution` | Always `True` | -| `shutdown_deadline_buffer` | 7 seconds | - -`disable_eager_activity_execution` is always `True` and cannot be overridden. Eager Activities require a persistent connection, which Lambda invocations don't maintain. - -`shutdown_deadline_buffer` is specific to the `lambda_worker` package. It controls how much time before the Lambda deadline the Worker begins its graceful shutdown. The default is `graceful_shutdown_timeout` + 2 seconds. - -If your Worker handles long-running Activities, increase `graceful_shutdown_timeout`, `shutdown_deadline_buffer`, and the Lambda invocation deadline (`--timeout`) together. - -### Connection configuration - -The `lambda_worker` package automatically loads Temporal client configuration from a TOML config file and environment variables (see the Environment Configuration docs, `/develop/environment-configuration`). - -TOML config file resolution order: - -1. `TEMPORAL_CONFIG_FILE` environment variable, if set. -2. `temporal.toml` in `$LAMBDA_TASK_ROOT` (typically `/var/task`). -3. `temporal.toml` in the current working directory. - -The file is optional. If absent, only environment variables are used. - ---- - -## Java SDK - -### Package - -Import: `io.temporal.aws.lambda.LambdaWorker`, `io.temporal.aws.lambda.LambdaWorkerOptions`, `io.temporal.common.WorkerDeploymentVersion` - -Install: `io.temporal:temporal-aws-lambda` — a **separate Maven artifact** from `io.temporal:temporal-sdk`, but published on the **same version line** (both 1.38.0). This is a third packaging pattern: unlike Go and TypeScript it is not independently versioned, and unlike Python it does not ship inside the main SDK. Use `io.temporal:temporal-bom` in `dependencyManagement` to keep them aligned. - -```xml - - - - io.temporaltemporal-bom - 1.38.0pomimport - - - -``` - -`aws-lambda-java-core` (1.4.0) arrives transitively from `temporal-aws-lambda`; declare it explicitly if you compile against `RequestHandler`/`Context`. - -### Entry point - -**`LambdaWorker.define(version, configure)`** — returns a `RequestHandler` that your handler class delegates to. There are four public overloads: `define` (2- and 3-arg) and `newHandler` (2- and 3-arg, taking a pre-built `LambdaWorkerOptions`). - -Note that Java's entry point is not "run"-shaped like the other SDKs' (`RunWorker`, `run_worker`, `runWorker`) — confirm the method name against the version you install. - -### Configure callback — two phases, unlike the other SDKs - -Java splits configuration in a way no other SDK does, and the distinction matters: - -- The `Consumer` passed to `define` is *"invoked once while the Lambda handler is constructed"* — i.e. at **cold start**, once per container, **not** per invocation. -- Per-invocation configuration is a **separate** callback, `LambdaWorker.InvocationConfigurator`, taking `(LambdaWorkerOptions.Builder, com.amazonaws.services.lambda.runtime.Context)`, *"invoked for each Lambda invocation before Temporal service stubs, client, and worker are created."* Use the 3-arg `define` overload for it. - -Contrast Python, whose `configure` runs **once per invocation**. Do not describe them as equivalent, and do not carry per-invocation logic into Java's cold-start callback. - -Registration methods on `LambdaWorkerOptions.Builder`: `setTaskQueue`, `registerWorkflowImplementationTypes`, `registerDynamicWorkflowImplementationType`, `registerWorkflowImplementationFactory` (3 overloads), `registerActivitiesImplementations`, `registerDynamicActivityImplementation`, `registerNexusServiceImplementation`, `addShutdownHook`, plus `getWorkerOptionsBuilder()` / `getWorkflowClientOptionsBuilder()` / `getWorkflowServiceStubsOptionsBuilder()` for lower-level tuning. - -### Versioning behavior - -Per-Workflow via the **annotation** `io.temporal.workflow.WorkflowVersioningBehavior` on the workflow method, taking `io.temporal.common.VersioningBehavior.PINNED` or `.AUTO_UPGRADE`: - -```java -public class GreetingWorkflowImpl implements GreetingWorkflow { - @Override - @WorkflowVersioningBehavior(VersioningBehavior.PINNED) - public String getGreeting(String name) { ... } -} -``` - -Or a Worker-level default with `DefaultVersioningBehavior` in `DeploymentOptions`. - -### Lambda-tuned defaults - - - -| Setting | Lambda default | -|---|---| -| `MaxConcurrentActivityExecutionSize` | 2 | -| `MaxConcurrentWorkflowTaskExecutionSize` | 10 | -| `MaxConcurrentLocalActivityExecutionSize` | 2 | -| `MaxConcurrentNexusExecutionSize` | 5 | -| `MaxConcurrentWorkflowTaskPollers` | 2 | -| `MaxConcurrentActivityTaskPollers` | 1 | -| `MaxConcurrentNexusTaskPollers` | 1 | -| `WorkflowCacheSize` | 30 | -| `MaxWorkflowThreadCount` | 30 | -| `GracefulShutdownTimeout` | 5 seconds | -| `ShutdownDeadlineBuffer` | 7 seconds | - -`MaxWorkflowThreadCount` has no counterpart in the other SDKs — Java runs Workflow code on real threads. - -Eager Activities are disabled: `builder.setDisableEagerExecution(true)` (`LambdaWorkerOptions.java:258`). `ShutdownDeadlineBuffer` defaults to `GracefulShutdownTimeout` + 2s, the same relationship as the other SDKs. - -### Logging — the binding must be SLF4J 1.7.x - -The Java SDK compiles against `org.slf4j:slf4j-api:1.7.36`. A 2.x provider (`slf4j-simple:2.x`, Logback 1.3+) **will not bind to a 1.7 API**, and the Worker runs with no logs at all — the same silent outcome as Python's `logging.basicConfig()` no-op, by a different mechanism. Use a 1.7.x provider: - -```xml - - org.slf4jslf4j-simple1.7.36 - -``` - -With a correct binding the module logs its own lifecycle unprompted, which is more than the other SDKs give you by default: - -``` -[main] INFO io.temporal.aws.lambda.LambdaWorker - Temporal Lambda worker started - awsRequestId= invokedFunctionArn= taskQueue= identity=@ -``` - -### Connection configuration - -Loaded automatically from environment variables and an optional TOML config file. Public constants on `LambdaWorkerOptions`: `TEMPORAL_TASK_QUEUE`, `TEMPORAL_CONFIG_FILE`, `LAMBDA_TASK_ROOT`. - -Resolution order (`LambdaWorkerOptions.resolveConfigFilePath`): - -1. `TEMPORAL_CONFIG_FILE` environment variable, if set. -2. `temporal.toml` in `$LAMBDA_TASK_ROOT` (typically `/var/task`). -3. `temporal.toml` in the current working directory. - -**`HOME=/tmp` is not required for Java** — unlike the Go and TypeScript examples. The module never reads `HOME`; when no file is found it passes a null path to `ClientConfig.load`, which falls back to `/.config/temporalio/temporal.toml` and treats both a missing home directory and a `FileNotFoundException` as "empty config, no error". It is a read, not a write, so Lambda's read-only filesystem is not involved. Note also that Java reads the `user.home` **system property**, not the `HOME` environment variable, so setting `HOME` is not even the right lever — use `-Duser.home` via `JAVA_TOOL_OPTIONS` if you ever need to steer it. - ---- - -## TypeScript SDK - -### Package - -Import: `import { runWorker } from '@temporalio/lambda-worker'` - -Install: `npm install @temporalio/lambda-worker` — a separate npm package from `@temporalio/worker`, versioned independently. - -### Entry point - -`runWorker` — creates a Lambda handler that runs a Temporal Worker. Pass a deployment version and a configure callback. - -### Configure callback - -Set Worker options via `config.workerOptions`. For Workflow code, use `workflowBundle` with pre-bundled code instead of `workflowsPath` to avoid webpack bundling overhead on Lambda cold starts. - -### Pre-bundling Workflow code - -Build the bundle as a separate build step: - -```typescript -import { bundleWorkflowCode } from '@temporalio/worker'; -import { writeFile } from 'fs/promises'; - -const { code } = await bundleWorkflowCode({ - workflowsPath: require.resolve('./workflows'), -}); -await writeFile('./workflow-bundle.js', code); -``` - - -Then reference the bundle in your handler with `workflowBundle: { codePath: require.resolve('./workflow-bundle.js') }`. - -### Versioning behavior - -Set per-Workflow with `setWorkflowOptions` in the Workflow file, or set a default for all Workflows with `defaultVersioningBehavior` in the configure callback. -Values are `'PINNED'` or `'AUTO_UPGRADE'`. The default versioning behavior is `PINNED`. - -Access via: `config.workerOptions.workerDeploymentOptions!.defaultVersioningBehavior = 'PINNED'` - -### Lambda-tuned defaults - - - -| Setting | Lambda default | -|---|---| -| `maxConcurrentActivityTaskExecutions` | 2 | -| `maxConcurrentWorkflowTaskExecutions` | 10 | -| `maxConcurrentLocalActivityExecutions` | 2 | -| `maxConcurrentNexusTaskExecutions` | 5 | -| `workflowTaskPollerBehavior` | `SimpleMaximum(2)` | -| `activityTaskPollerBehavior` | `SimpleMaximum(1)` | -| `nexusTaskPollerBehavior` | `SimpleMaximum(1)` | -| `shutdownGraceTime` | 5 seconds | -| `maxCachedWorkflows` | 30 | -| `shutdownDeadlineBufferMs` | 7000 | - -Eager Activities are not supported. Lambda invocations don't maintain persistent connections. - -`shutdownDeadlineBufferMs` is specific to the `@temporalio/lambda-worker` package. It controls how much time before the Lambda deadline the Worker begins its graceful shutdown. The default is `shutdownGraceTime` (5s) + 2s. - -If your Worker handles long-running Activities, increase `shutdownGraceTime`, `shutdownDeadlineBufferMs`, and the Lambda invocation deadline (`--timeout`) together. - -### Connection configuration - -The `@temporalio/lambda-worker` package automatically loads Temporal client configuration from a TOML config file and environment variables (see the Environment Configuration docs, `/develop/environment-configuration`). - -TOML config file resolution order: - -1. `TEMPORAL_CONFIG_FILE` environment variable, if set. -2. `temporal.toml` in `$LAMBDA_TASK_ROOT` (typically `/var/task`). -3. `temporal.toml` in the current working directory. - -The file is optional. If absent, only environment variables are used. - ---- - -## Cross-SDK comparison: Lambda-tuned defaults - -| Concept | Go | Python | TypeScript | Java | -|---|---|---|---|---| -| Max concurrent activities | `MaxConcurrentActivityExecutionSize` = 2 | `max_concurrent_activities` = 2 | `maxConcurrentActivityTaskExecutions` = 2 | `MaxConcurrentActivityExecutionSize` = 2 | -| Max concurrent workflow tasks | `MaxConcurrentWorkflowTaskExecutionSize` = 10 | `max_concurrent_workflow_tasks` = 10 | `maxConcurrentWorkflowTaskExecutions` = 10 | `MaxConcurrentWorkflowTaskExecutionSize` = 10 | -| Sticky cache size | 100 | `max_cached_workflows` = 30 | `maxCachedWorkflows` = 30 | `WorkflowCacheSize` = 30 | -| Worker stop timeout | `WorkerStopTimeout` = 5s | `graceful_shutdown_timeout` = 5s | `shutdownGraceTime` = 5s | `GracefulShutdownTimeout` = 5s | -| Shutdown deadline buffer | `ShutdownDeadlineBuffer` = 7s | `shutdown_deadline_buffer` = 7s | `shutdownDeadlineBufferMs` = 7000 | `ShutdownDeadlineBuffer` = 7s | -| Eager activities | `DisableEagerActivities` always true | `disable_eager_activity_execution` always `True` | Not supported | `setDisableEagerExecution(true)` | -| Entry point | `RunWorker` | `run_worker` | `runWorker` | `LambdaWorker.define` | -| Configure callback runs | per invocation | per invocation | per invocation | **at cold start**; separate `InvocationConfigurator` for per-invocation | -| Package relationship to SDK | separate module, own version line | inside main SDK | separate npm package, own version line | separate artifact, **same version line** | - -Java-only: `MaxWorkflowThreadCount` = 30 (no counterpart elsewhere — Java runs Workflow code on real threads). - - - - - -Note: Go sticky cache size is 100, while Python and TypeScript are 30. These values come from each SDK's own docs and are not interchangeable. From 51ffbd9c476720ddf7850cc731faa9cc830ed8ec Mon Sep 17 00:00:00 2001 From: starfleeth <128422269+starfleeth@users.noreply.github.com> Date: Tue, 1 Sep 2026 19:41:00 -0700 Subject: [PATCH 2/6] Restore verbatim environment example --- references/aws-lambda/setup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/references/aws-lambda/setup.md b/references/aws-lambda/setup.md index 6fbb102..34db17d 100644 --- a/references/aws-lambda/setup.md +++ b/references/aws-lambda/setup.md @@ -152,7 +152,7 @@ See the selected SDK reference's **Build and package** section. ```bash cat > /tmp/lambda-env.json < Date: Thu, 3 Sep 2026 14:51:21 -0700 Subject: [PATCH 3/6] Changes to add .NET SDK support (#12) * Add .NET SDK support for Serverless Workers on AWS Lambda Documents the .NET SDK alongside Go, Python, TypeScript, and Java, verified against Temporalio.Extensions.Aws.Lambda 1.18.0 (public API read from the package's own XML documentation) and samples-dotnet@main src/LambdaWorker, which is maintained code with a test project. .NET specifics documented: - Separate NuGet package in lockstep with Temporalio 1.18.0, with OpenTelemetry in a second package rather than an extra on the first. - TemporalLambdaWorker.CreateHandler as the entry point, with sync and async configure overloads; registrations go through WorkerOptions. - Publish must be RID-specific (--runtime linux-x64 / linux-arm64): the SDK wraps a native Rust core, libtemporalio_sdk_core_c_bridge.so, which a portable publish omits. This is .NET's equivalent of Python's manylinux wheels and Go's GOARCH, with the same first-invocation failure mode. Includes the sample's presence check. - The handler string has three colon-separated parts, ASSEMBLY::NAMESPACE.TYPE::METHOD -- the only SDK with that shape. - Worker-level default versioning behavior is AutoUpgrade, where TypeScript's is PINNED. Defaults are not uniform; set them explicitly. - The SSL_CERT_FILE / root CA issue on some Lambda .NET images, which presents as a TLS failure that is not a configuration problem. - Telemetry IAM permissions and --tracing-config Mode=Active, from the sample's enable-telemetry.sh. Also corrects the sample location: the docs link to a branch (blob/ea/aws-lambda) that no longer exists; the sample is on main at src/LambdaWorker. Note that .NET uses --timeout 600 and --memory-size 256, the same as Go, Python and TypeScript, which supports reading Java's 90/1024 as a Java-specific choice rather than a documentation inconsistency. Co-Authored-By: Claude Opus 5 (1M context) * Fold findings from a real .NET deployment into the skill Deployed a .NET hello-world Worker end to end on Lambda. Three findings, none of which came from reading documentation. SSL_CERT_FILE is required, not optional. An otherwise-correct .NET deployment fails its first invocation with: Connection failed: Server connection error: tonic::transport::Error(Transport, NativeCertsNotFound) because AWS's .NET 8 Lambda images force-override SSL_CERT_FILE and the SDK's Rust core cannot load system root CAs. The variable now appears in the .NET create-function block and the environment-variable table rather than only in troubleshooting, since without it the deployment does not work at all. The error is also actively misleading: "certs not found" refers to the OS root CA store, not to any credential, and the connection fails before authentication is attempted. Diagnostics now says so explicitly and gives two discriminators, because the natural response -- checking the API key, Namespace, invocation role and External ID -- is wasted effort. Only .NET is affected: Python shares the Rust core but its runtime image does not override the variable, and Java uses the JVM truststore. Workflow.Logger is silent by default in .NET, because TemporalWorkerOptions.LoggerFactory defaults to the client's, which is also unset. Activity Console.WriteLine still reaches CloudWatch, so the gap looks selective rather than total. That completes a set of three SDKs with three unrelated causes for the same symptom. Also adds a caution to iam.md: read the invocation role's policy back after any update-stack that changes LambdaFunctionARNs. UPDATE_COMPLETE does not mean the ARNs are well-formed, the list is replaced rather than merged, and malformed entries silently revoke access for every function they omit. Includes the zsh $VAR:l expansion trap that produced exactly that outcome during this run. Co-Authored-By: Claude Opus 5 (1M context) * minor updates to readme/sdk config * minor edits to fix unverifed reference to files * updates to some .net specifics * removing .NET related change * updates to code references again * minor fix based on copilot suggestion * Carry dotnet-sdk-support's Java citation fixes into sdk-java.md The merged branch corrected four unverified doc citations in setup.md's Java create-function section. The SDK-reference refactor had moved that text to sdk-java.md, so resolving the merge in favour of the new structure dropped them. Apply them where the text now lives. Co-Authored-By: Claude Opus 5 (1M context) * adding minor change to the top level skill md file * Drops prose that argues for rules the bold leads already state. No rule or technical claim changes. - SKILL.md: remove trailing rationale from four rules; correct the pre-question note to point at steps 2 and 3, not step 2 alone. - sdk-*.md: drop "useful" from the "Ordering when sources disagree" heading, which the refactor had copied into all five files. * remove redundant/repeated information * addressing review comment - reducing verbosity * updated based on review comments * addressed partial set of review comments * addressing comments to leave java-specific changes out of this pr --------- Co-authored-by: Claude Opus 5 (1M context) --- README.md | 9 +- SKILL.md | 4 +- references/aws-lambda/diagnostics.md | 4 +- references/aws-lambda/observability.md | 1 + references/aws-lambda/sdk-dotnet.md | 267 ++++++++++++++++++++++++ references/aws-lambda/sdk-go.md | 2 +- references/aws-lambda/sdk-python.md | 2 +- references/aws-lambda/sdk-typescript.md | 2 +- references/aws-lambda/setup.md | 3 +- 9 files changed, 285 insertions(+), 9 deletions(-) create mode 100644 references/aws-lambda/sdk-dotnet.md diff --git a/README.md b/README.md index 161302d..2567adb 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ Deploy and operate [Temporal](https://temporal.io/) Workers on serverless comput ## What the skill can do -- Build Serverless Workers with the Go, Python, TypeScript, or Java SDK. +- Build Serverless Workers with the Go, Python, TypeScript, Java, or .NET SDK. - Package and deploy Workers to AWS Lambda with the correct architecture, timeout, and shutdown settings. - Configure the separate AWS roles used by the Lambda function and by Temporal. - Register a Worker Deployment Version, validate its Task Queue binding, and set it current. @@ -26,7 +26,7 @@ Deploy and operate [Temporal](https://temporal.io/) Workers on serverless comput |---|---| | Compute | AWS Lambda — Public Preview | | Temporal | Temporal Cloud and self-hosted Temporal Service | -| SDKs | Go, Python, TypeScript, Java | +| SDKs | Go, Python, TypeScript, Java, .NET | | Other compute providers | Not currently supported | For Temporal Cloud, the Namespace must be hosted on AWS. The Namespace and Lambda function may be in different AWS regions. @@ -94,6 +94,10 @@ Add OpenTelemetry tracing to my Go Serverless Worker on Lambda. Package this Java Worker as a shaded jar and deploy it to Lambda. ``` +```text +Deploy this .NET Worker to Lambda with a runtime-specific publish. +``` + For a new deployment, the skill follows five stages: 1. **Scope** — confirm the SDK, compute provider, Namespace, region, and resource-naming prefix. @@ -124,6 +128,7 @@ Nothing is created before you approve the resource list. Troubleshooting and ins | [`references/aws-lambda/sdk-python.md`](references/aws-lambda/sdk-python.md) | Python package, API, handler, build, packaging, Lambda deployment values, tuned defaults, connection configuration, OpenTelemetry integration, and diagnostics | | [`references/aws-lambda/sdk-typescript.md`](references/aws-lambda/sdk-typescript.md) | TypeScript package, API, handler, Workflow pre-bundling, build, packaging, Lambda deployment values, tuned defaults, connection configuration, and OpenTelemetry integration | | [`references/aws-lambda/sdk-java.md`](references/aws-lambda/sdk-java.md) | Java artifact, API, handler, callbacks, build, packaging, Lambda deployment values, tuned defaults, connection configuration, OpenTelemetry integration, logging, and diagnostics | +| [`references/aws-lambda/sdk-dotnet.md`](references/aws-lambda/sdk-dotnet.md) | .NET package, API, handler, build, RID-specific publish, Lambda deployment values, tuned defaults, connection configuration, OpenTelemetry integration, logging, and diagnostics | | [`references/aws-lambda/setup.md`](references/aws-lambda/setup.md) | Shared AWS and Temporal deployment lifecycle, verification, and teardown workflow | | [`references/aws-lambda/iam.md`](references/aws-lambda/iam.md) | Operator permissions, Lambda execution role, and Temporal invocation role | | [`references/aws-lambda/diagnostics.md`](references/aws-lambda/diagnostics.md) | Diagnostic decision tree and WCI inspection | diff --git a/SKILL.md b/SKILL.md index 3a1462d..9c825a5 100644 --- a/SKILL.md +++ b/SKILL.md @@ -27,6 +27,7 @@ Every supported provider's directory carries the same shared layout — `setup.m | Python | `references/aws-lambda/sdk-python.md` | | TypeScript | `references/aws-lambda/sdk-typescript.md` | | Java | `references/aws-lambda/sdk-java.md` | +| .NET | `references/aws-lambda/sdk-dotnet.md` | **Public Preview is not GA.** The APIs are still evolving and may change: pin SDK and CLI versions for anything long-lived, and read the installed package's actual API surface rather than writing from memory. @@ -90,7 +91,7 @@ Where the harness has a todo list, use it *in addition to* the printed checklist **A step is complete when its verification passed — not when its command exited zero.** Several commands in this workflow exit clean having done nothing: the traffic-shifting and key-revocation commands no-op when their confirmation prompt goes unanswered, and providers return from create and update calls while the resource is still settling. Check an item off against state you read back, not against an exit code. When a step's verification fails, say which step you are on and what it is blocked on rather than moving down the list. -1. **Scope the task.** Identify the SDK language (Go, Python, TypeScript, or Java), the deployment target (Temporal Cloud or self-hosted — self-hosted has its own server prerequisites), the compute provider, and whether this is a new setup, a configuration change, or troubleshooting. Confirm the deployment target is compatible with the chosen provider — see "A Namespace on the target cloud provider is required" under Provider-neutral principles. Ensure a Temporal client/CLI is available and authenticated to the target. Each changes the specifics. → `references/concepts.md` for what the user is building; `references//setup.md` for the compatibility and client-setup details. +1. **Scope the task.** Identify the SDK language (Go, Python, TypeScript, Java, or .NET), the deployment target (Temporal Cloud or self-hosted — self-hosted has its own server prerequisites), the compute provider, and whether this is a new setup, a configuration change, or troubleshooting. Confirm the deployment target is compatible with the chosen provider — see "A Namespace on the target cloud provider is required" under Provider-neutral principles. Ensure a Temporal client/CLI is available and authenticated to the target. Each changes the specifics. → `references/concepts.md` for what the user is building; `references//setup.md` for the compatibility and client-setup details. **Put the compute provider in that batch of questions as a confirmable default, not a free choice.** Pre-select the supported provider from the table above and carry its support status in the option's description. The user confirms rather than chooses, so it costs no extra turn, but the provider is never something they were assumed into. Skip the question only when the request already names a provider. Do not restate any of this in a paragraph before the questions; the option description is where it belongs. @@ -229,6 +230,7 @@ Most questions need 2–3 reference files. | Python SDK-specific options and tuned defaults, package and import, API inspection, handler, build and packaging, runtime and deployment values, versioning-behavior configuration, connection config, OpenTelemetry integration, diagnostic signatures. | `references//sdk-python.md` | | TypeScript SDK-specific options and tuned defaults, package and import, API inspection, handler, build and packaging, runtime and deployment values, versioning-behavior configuration, connection config, pre-bundled Workflow code, OpenTelemetry integration. | `references//sdk-typescript.md` | | Java SDK-specific options and tuned defaults, artifact and imports, API inspection, handler, build and packaging, runtime and deployment values, versioning-behavior configuration, connection config, OpenTelemetry integration, logging and diagnostic signatures. | `references//sdk-java.md` | +| .NET SDK-specific options and tuned defaults, package and imports, API inspection, handler, RID-specific publish and packaging, runtime and deployment values, versioning-behavior configuration, connection config and `SSL_CERT_FILE`, OpenTelemetry integration, logging and diagnostic signatures. | `references//sdk-dotnet.md` | | Add OpenTelemetry observability, Collector config, X-Ray, and IAM. | `references//observability.md` + the selected `references//sdk-.md` | | Worker not invoked, Workflows not progressing, inspect the WCI. | `references//diagnostics.md` + the selected `references//sdk-.md` (+ `references/concepts.md`) | | Long-running Activities and timeout relationships. Isolate Activities from resource exhaustion. | `references/concepts.md` (+ the selected `references//sdk-.md`) | diff --git a/references/aws-lambda/diagnostics.md b/references/aws-lambda/diagnostics.md index b1d2750..2d4ac73 100644 --- a/references/aws-lambda/diagnostics.md +++ b/references/aws-lambda/diagnostics.md @@ -125,9 +125,9 @@ Common errors include: ### Language-specific signatures -**No application logs at all, but the Worker clearly ran.** Two different SDKs produce this same misleading silence by unrelated mechanisms, and in both cases the Worker is healthy — only the logging is broken. Diagnose invocation health from Lambda's own runtime markers (`INIT_START`/`START`/`END`/`REPORT`) and CloudWatch metrics instead, then fix the binding. +**No application logs at all, but the Worker clearly ran.** SDK-specific logging configuration can suppress application logs even when the Worker is healthy. Diagnose invocation health from Lambda's runtime markers (`INIT_START`/`START`/`END`/`REPORT`) and CloudWatch metrics. -For SDK-specific diagnostics, see the selected SDK reference. +For the exact logging cause and fix, see the selected SDK reference. ### Check for Lambda timeout diff --git a/references/aws-lambda/observability.md b/references/aws-lambda/observability.md index 6d8537f..0492608 100644 --- a/references/aws-lambda/observability.md +++ b/references/aws-lambda/observability.md @@ -12,6 +12,7 @@ Load the selected SDK reference's **Observability** section: | Python | `sdk-python.md` → Observability | | TypeScript | `sdk-typescript.md` → Observability | | Java | `sdk-java.md` → Observability | +| .NET | `sdk-dotnet.md` → Observability | The remaining steps in this file are shared across SDKs. diff --git a/references/aws-lambda/sdk-dotnet.md b/references/aws-lambda/sdk-dotnet.md new file mode 100644 index 0000000..4e385dc --- /dev/null +++ b/references/aws-lambda/sdk-dotnet.md @@ -0,0 +1,267 @@ +# .NET SDK on AWS Lambda + +Sources: [`Temporalio.Extensions.Aws.Lambda` 1.18.0](https://www.nuget.org/packages/Temporalio.Extensions.Aws.Lambda/1.18.0), [Lambda extension source](https://github.com/temporalio/sdk-dotnet/tree/90c4ef35e260ed5bf553de7ef458053da28e3912/src/Temporalio.Extensions.Aws.Lambda), [OpenTelemetry extension source](https://github.com/temporalio/sdk-dotnet/tree/90c4ef35e260ed5bf553de7ef458053da28e3912/src/Temporalio.Extensions.Aws.Lambda.OpenTelemetry), and the [maintained Lambda Worker sample](https://github.com/temporalio/samples-dotnet/tree/6aba4fb9ea08177e303352ec9a4c61e303cefb0e/src/LambdaWorker). + +Use this reference for .NET SDK-specific package, entry-point, Worker configuration, tuned defaults, observability, and diagnostic details. For shared AWS Lambda deployment, observability infrastructure, and diagnostic flow, see `setup.md`, `observability.md`, and `diagnostics.md`. + +## Package + +Import: `using Temporalio.Extensions.Aws.Lambda;` plus `Temporalio.Common` (for `WorkerDeploymentVersion`) and `Amazon.Lambda.Core` (for `ILambdaContext`). + +Install: `dotnet add package Temporalio.Extensions.Aws.Lambda` — a **separate NuGet package** from `Temporalio`, published in **lockstep** with it (both 1.18.0). Published versions: 1.17.0 and 1.18.0. The package targets `netstandard2.0` and declares `Temporalio` 1.18.0 and `Amazon.Lambda.Core` 3.1.0. + +OpenTelemetry lives in a **second package**, `Temporalio.Extensions.Aws.Lambda.OpenTelemetry` (also 1.18.0). → Observability below. + +- .NET: [.NET Lambda Worker sample](https://github.com/temporalio/samples-dotnet/tree/6aba4fb9ea08177e303352ec9a4c61e303cefb0e/src/LambdaWorker) — `Worker/`, `Starter/`, and `Deploy/` (deploy, IAM-role, execution-role, and telemetry scripts plus a CloudFormation template), with a test project under `tests/LambdaWorker`. + +List the real public API of the resolved package before generating code — the `.nupkg` is a zip and ships full XML documentation: + +```bash +curl -sO https://api.nuget.org/v3-flatcontainer/temporalio.extensions.aws.lambda//temporalio.extensions.aws.lambda..nupkg +unzip -p temporalio.extensions.aws.lambda..nupkg \ + lib/netstandard2.0/Temporalio.Extensions.Aws.Lambda.xml +# the .nuspec lists the exact dependency versions: +unzip -p ...nupkg Temporalio.Extensions.Aws.Lambda.nuspec | grep dependency +``` + +If sources disagree, use the installed artifact's public API, followed by the maintained sample and the prose documentation. + +## Entry point + +**`TemporalLambdaWorker.CreateHandler(version, configure)`** — returns a `Func` that your handler method delegates to. Overloads take either a synchronous `Action` or an asynchronous `Func` for setup that must await. A further overload taking `TemporalLambdaWorkerHandlerOptions` is an internal test seam and is not for production use. + +## Configure callback + +Receives a `TemporalLambdaWorkerOptions` with public `ClientOptions`, `WorkerOptions`, `ShutdownDeadlineBuffer`, and `AddShutdownHook(Func)` members. The Task Queue and registrations go through `WorkerOptions` — an ordinary `TemporalWorkerOptions`, so `TaskQueue`, `AddWorkflow()` and `AddActivity(...)` behave exactly as they do for a long-lived Worker. The callback runs **per invocation**. + +## Versioning behavior + +Per-Workflow via the `[Workflow]` attribute: + +```csharp +[Workflow(VersioningBehavior = VersioningBehavior.Pinned)] +public class MyWorkflow +{ + [WorkflowRun] + public async Task RunAsync(string name) => /* ... */; +} +``` + +Or a Worker-level default through `DefaultVersioningBehavior` in `DeploymentOptions`. + +**The .NET Worker-level default is `AutoUpgrade`.** Prefer setting the behavior explicitly per Workflow. + +## Handler example + +A plain class exposes an async method that delegates to the handler returned by `TemporalLambdaWorker.CreateHandler`. + +```csharp +namespace MyCompany.Temporal.Worker; + +using Amazon.Lambda.Core; +using Temporalio.Common; +using Temporalio.Extensions.Aws.Lambda; + +public class LambdaFunction +{ + private static readonly Func WorkerHandler = + TemporalLambdaWorker.CreateHandler( + new WorkerDeploymentVersion("my-app", "build-1"), + config => + { + config.WorkerOptions.TaskQueue = "my-task-queue"; + config.WorkerOptions + .AddWorkflow() + .AddActivity(MyActivities.MyActivity); + }); + + public Task HandlerAsync(Stream input, ILambdaContext context) => + WorkerHandler(input, context); +} +``` + +Registrations go through `config.WorkerOptions`, an ordinary `TemporalWorkerOptions` — the same API a long-lived Worker uses. Use the `Func` overload when setup must await. + +## Lambda-tuned defaults + + + +| Setting | Lambda default | +|---|---| +| `MaxConcurrentActivities` | 2 | +| `MaxConcurrentWorkflowTasks` | 10 | +| `MaxConcurrentLocalActivities` | 2 | +| `MaxConcurrentNexusTasks` | 5 | +| `MaxConcurrentWorkflowTaskPolls` | 2 | +| `MaxConcurrentActivityTaskPolls` | 1 | +| `MaxConcurrentNexusTaskPolls` | 1 | +| `MaxCachedWorkflows` | 30 | +| `GracefulShutdownTimeout` | 5 seconds | +| `ShutdownDeadlineBuffer` | 7 seconds | +| `DisableEagerActivityExecution` | Always `true`, cannot be overridden | + +## Logging — set a LoggerFactory or Workflow logs vanish + +`TemporalWorkerOptions.LoggerFactory` is unset by default and "defaults to the client logger factory", which is also unset — so `Workflow.Logger` output is discarded. Activity `Console.WriteLine` still reaches CloudWatch, which makes the gap look selective rather than total. + +Install the console logging provider: + +```bash +dotnet add package Microsoft.Extensions.Logging.Console +``` + +```csharp +using Microsoft.Extensions.Logging; + +config.WorkerOptions.LoggerFactory = + LoggerFactory.Create(b => b.AddSimpleConsole().SetMinimumLevel(LogLevel.Information)); +``` + +## Connection configuration + +Loaded automatically from environment variables and an optional TOML config file, in this resolution order: + +1. `TEMPORAL_CONFIG_FILE` environment variable, if set. +2. `temporal.toml` in the Lambda task root (typically `/var/task`). +3. `temporal.toml` in the current working directory. + +When using `temporal.toml`, copy it into the publish directory before zipping so it lands in the task root. Keep the API key in `TEMPORAL_API_KEY` rather than in the file; supplying an API key enables TLS automatically. + +**TLS caveat specific to .NET — set `SSL_CERT_FILE` or the first invocation fails.** AWS's .NET 8 Lambda images force-override `SSL_CERT_FILE`, which prevents the SDK's Rust core from loading system root CAs. Set it explicitly on the function: + +``` +SSL_CERT_FILE=/etc/pki/tls/certs/ca-bundle.crt # or /etc/ssl/certs/ca-certificates.crt +``` + +**This is server-certificate verification, not client credentials.** The API key is unaffected and is not the problem — an API key auto-enables TLS, and TLS requires verifying Temporal Cloud's certificate chain against root CAs. The connection fails before authentication is ever attempted. See `diagnostics.md` for the corresponding failure signature and recovery steps. + +## Build and package + +### Native dependency — publish must be RID-specific + +The .NET SDK wraps a **native Rust core** (`libtemporalio_sdk_core_c_bridge.so`). For Lambda, publish for an explicit runtime identifier matching the function's architecture and confirm the native library is present before creating the zip: + +| `--runtime` | `--architectures` | +|---|---| +| `linux-x64` | `x86_64` | +| `linux-arm64` | `arm64` | + +Publish for an explicit Linux runtime identifier, then zip the publish output. + +```bash +dotnet publish path/to/Worker.csproj \ + --configuration Release \ + --runtime linux-x64 \ + --self-contained false \ + --output ./publish + +# Guard: the SDK's native Rust bridge must be in the output, or the function +# fails at FIRST INVOCATION, not at build time. +[[ -f ./publish/libtemporalio_sdk_core_c_bridge.so ]] || { + echo "Publish output is missing the linux-x64 Temporal native bridge." >&2; exit 1; } + +# Copy each optional configuration file that this deployment uses so it lands +# in the Lambda task root: +if [[ -f temporal.toml ]]; then + cp temporal.toml ./publish/ +fi +if [[ -f otel-collector-config.yaml ]]; then + cp otel-collector-config.yaml ./publish/ +fi + +cd ./publish && zip -r ../function.zip . && cd .. +``` + +Keep the native-library check before zipping. `--self-contained false` is correct because the `dotnet8` managed runtime supplies the framework. + +## Deploy the Lambda function + +```bash +aws lambda create-function \ + --function-name my-temporal-worker \ + --runtime dotnet8 \ + --architectures x86_64 \ + --handler 'MyAssembly::MyCompany.Temporal.Worker.LambdaFunction::HandlerAsync' \ + --role \ + --zip-file fileb://function.zip \ + --timeout 600 \ + --memory-size 256 \ + --environment file:///tmp/lambda-env.json +``` + +**The environment block for .NET must include `SSL_CERT_FILE`**, in addition to the usual `TEMPORAL_*` variables: + +```json +{"Variables":{ + "TEMPORAL_ADDRESS":"...", "TEMPORAL_NAMESPACE":"...", "TEMPORAL_API_KEY":"...", + "SSL_CERT_FILE":"/etc/pki/tls/certs/ca-bundle.crt"}} +``` + +Without it the **first invocation fails**, the Task Queue is never bound, and the Worker is never invoked again. AWS's .NET 8 Lambda images force-override `SSL_CERT_FILE`, which stops the SDK's Rust core from loading system root CAs. `/etc/ssl/certs/ca-certificates.crt` also works; try the other if one fails. This is server-certificate verification, unrelated to your API key. → `diagnostics.md`. + +- `--runtime`: `dotnet8` for a `net8.0` build. +- `--handler`: **`ASSEMBLY::NAMESPACE.TYPE::METHOD` — three colon-separated parts.** Getting this wrong presents as a handler-not-found error at first invocation. +- `--timeout 600` / `--memory-size 256` are example values. The timeout must accommodate Worker startup and registration, Task and Activity processing, and graceful shutdown. Memory contributes directly to Lambda cost. → `setup.md` for how to choose both values. +- `--architectures` must match the publish RID (`linux-x64` → `x86_64`, `linux-arm64` → `arm64`). + +## Observability + +### OTel package + +A **second NuGet package**, separate from the Lambda extension itself: + +```bash +dotnet add package Temporalio.Extensions.Aws.Lambda.OpenTelemetry +``` + +Published in lockstep with `Temporalio` and `Temporalio.Extensions.Aws.Lambda` (all 1.18.0). + +### OTel functions + +The package contributes an extension method on the options object, applied inside the configure callback: + +```csharp +using Temporalio.Extensions.Aws.Lambda.OpenTelemetry; + +TemporalLambdaWorker.CreateHandler( + new WorkerDeploymentVersion("my-app", "build-1"), + config => + { + config.ApplyOpenTelemetryDefaults(); + config.WorkerOptions.TaskQueue = "my-task-queue"; + config.WorkerOptions.AddWorkflow().AddActivity(MyActivities.MyActivity); + }); +``` + +`ApplyOpenTelemetryDefaults()` configures metrics and tracing against the ADOT layer's collector. Telemetry must be exported before the invocation ends — keep any metrics export interval shorter than the Lambda timeout. + +### ADOT layer setup + +Attach an **ADOT Collector layer** for the target region and architecture. No language-specific auto-instrumentation layer is needed because the OpenTelemetry SDK arrives as an ordinary package dependency. Supply the collector layer ARN for the target region. + +Set `OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/otel-collector-config.yaml` and copy `otel-collector-config.yaml` into the publish directory before zipping so it lands in the task root. + +For the shared Collector configuration, X-Ray enablement, and execution-role permissions, see `observability.md`. + +## Diagnostic signatures + +| SDK | Cause | Fix | +|---|---|---| +| .NET | `TemporalWorkerOptions.LoggerFactory` is unset and "defaults to the client logger factory", which is also unset — so `Workflow.Logger` output is discarded. Activity `Console.WriteLine` still reaches CloudWatch, which makes the gap look selective rather than total | set `config.WorkerOptions.LoggerFactory` (e.g. `LoggerFactory.Create(b => b.AddSimpleConsole().SetMinimumLevel(LogLevel.Information))`) | + +**.NET — `DllNotFoundException` / missing `libtemporalio_sdk_core_c_bridge.so` at first invocation.** Republish with an explicit runtime identifier matching the function's architecture (`--runtime linux-x64` for `x86_64`, `linux-arm64` for `arm64`) and check the native library is in the publish output before zipping. → Build and package above. + +**.NET — `NativeCertsNotFound` at first invocation, despite a correct address, Namespace, and API key.** + +``` +System.InvalidOperationException: Connection failed: Server connection error: + tonic::transport::Error(Transport, NativeCertsNotFound) + at Temporalio.Bridge.Client.ConnectAsync(...) + at Temporalio.Client.TemporalConnection.ConnectAsync(...) +``` + +*Cause:* AWS's .NET 8 Lambda images force-override `SSL_CERT_FILE`, so the SDK's Rust core cannot load system root CAs. *Fix:* set `SSL_CERT_FILE=/etc/pki/tls/certs/ca-bundle.crt` (or `/etc/ssl/certs/ca-certificates.crt`) on the function, then recover the binding as described under "Failed first invocation" in `diagnostics.md` — the failed validation invocation means no Task Queue was bound and Temporal will not retry on its own. + +"Certs" here means the operating system's root CA store, not client credentials. An API key auto-enables TLS, and TLS requires verifying the server's certificate chain. The connection fails before authentication is attempted, so changing the API key, Namespace, invocation role, or External ID will not fix this error. + +**.NET — handler not found at first invocation.** The handler string has **three** colon-separated parts, `ASSEMBLY::NAMESPACE.TYPE::METHOD`. Compare against the assembly name (not the project name, if they differ) and the fully-qualified type. diff --git a/references/aws-lambda/sdk-go.md b/references/aws-lambda/sdk-go.md index 8a2216e..0b57603 100644 --- a/references/aws-lambda/sdk-go.md +++ b/references/aws-lambda/sdk-go.md @@ -19,7 +19,7 @@ go doc go.temporal.io/sdk/contrib/aws/lambdaworker go doc go.temporal.io/sdk/contrib/aws/lambdaworker.Options ``` -**A useful ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs — Java's is `define`, not "run"-shaped like the others — so check rather than pattern-match from another language. +**Ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs, so check rather than pattern-match from another language. ## Entry point diff --git a/references/aws-lambda/sdk-python.md b/references/aws-lambda/sdk-python.md index 583b1d2..5d46172 100644 --- a/references/aws-lambda/sdk-python.md +++ b/references/aws-lambda/sdk-python.md @@ -18,7 +18,7 @@ Read the installed API before generating code: python -c "import temporalio.contrib.aws.lambda_worker as m; help(m.LambdaWorkerConfig)" ``` -**A useful ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs — Java's is `define`, not "run"-shaped like the others — so check rather than pattern-match from another language. +**Ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs, so check rather than pattern-match from another language. **Fastest path:** start from the language sample linked above — it has a working Worker, Workflow, and Activity already wired together. The handler example below imports the Workflow and Activity from separate modules (`my_workflows`, `my_activities`). When writing from scratch, create those modules with at least one registered Workflow (declaring a versioning behavior) and one Activity, and name the entry-point file to match the `--handler` you deploy (for example, `lambda_function.py` → `--handler lambda_function.lambda_handler`). diff --git a/references/aws-lambda/sdk-typescript.md b/references/aws-lambda/sdk-typescript.md index 603b1bb..a89a51e 100644 --- a/references/aws-lambda/sdk-typescript.md +++ b/references/aws-lambda/sdk-typescript.md @@ -18,7 +18,7 @@ Check the installed version, then read its type declarations: npm ls @temporalio/lambda-worker ``` -**A useful ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs — Java's is `define`, not "run"-shaped like the others — so check rather than pattern-match from another language. +**Ordering when sources disagree:** the installed artifact first, the SDK's maintained samples second (they are built in CI, so they cannot reference a method that does not exist), the prose docs last. Entry-point names are not consistent across SDKs, so check rather than pattern-match from another language. ## Entry point diff --git a/references/aws-lambda/setup.md b/references/aws-lambda/setup.md index 34db17d..30083bd 100644 --- a/references/aws-lambda/setup.md +++ b/references/aws-lambda/setup.md @@ -16,7 +16,7 @@ This is the end-to-end golden path: connect, write the Worker, package and deplo - Every Workflow must declare a versioning behavior, or the Worker must set a default versioning behavior. - An AWS account with permissions to create and invoke Lambda functions and create IAM roles. For the exact operator actions and a preflight check, see `iam.md`. - The AWS-specific steps require the `aws` CLI installed and configured with your AWS credentials. You may also use the AWS Console or the AWS SDKs. -- The Go SDK, Python SDK, TypeScript SDK, or Java SDK, depending on your language. +- The Go SDK, Python SDK, TypeScript SDK, Java SDK, or .NET SDK, depending on your language. - The `temporal` CLI, authenticated to the target Temporal Service — Steps 4–6 and the CLI troubleshooting paths use it. See "Temporal CLI and Cloud connection" below. The selected SDK reference links its maintained sample project. @@ -123,6 +123,7 @@ Load the reference for the selected SDK alongside this shared deployment guide: | Python | `sdk-python.md` | | TypeScript | `sdk-typescript.md` | | Java | `sdk-java.md` | +| .NET | `sdk-dotnet.md` | Complete the selected SDK reference before continuing. From 8c6731eecc5c13d46de36626100b87e2f886c11b Mon Sep 17 00:00:00 2001 From: Amir Benvenisti <128422269+starfleeth@users.noreply.github.com> Date: Fri, 4 Sep 2026 08:44:35 -0500 Subject: [PATCH 4/6] Update references/aws-lambda/sdk-dotnet.md Co-authored-by: David Hyde --- references/aws-lambda/sdk-dotnet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/references/aws-lambda/sdk-dotnet.md b/references/aws-lambda/sdk-dotnet.md index 4e385dc..454a968 100644 --- a/references/aws-lambda/sdk-dotnet.md +++ b/references/aws-lambda/sdk-dotnet.md @@ -1,6 +1,6 @@ # .NET SDK on AWS Lambda -Sources: [`Temporalio.Extensions.Aws.Lambda` 1.18.0](https://www.nuget.org/packages/Temporalio.Extensions.Aws.Lambda/1.18.0), [Lambda extension source](https://github.com/temporalio/sdk-dotnet/tree/90c4ef35e260ed5bf553de7ef458053da28e3912/src/Temporalio.Extensions.Aws.Lambda), [OpenTelemetry extension source](https://github.com/temporalio/sdk-dotnet/tree/90c4ef35e260ed5bf553de7ef458053da28e3912/src/Temporalio.Extensions.Aws.Lambda.OpenTelemetry), and the [maintained Lambda Worker sample](https://github.com/temporalio/samples-dotnet/tree/6aba4fb9ea08177e303352ec9a4c61e303cefb0e/src/LambdaWorker). +Sources: [`Temporalio.Extensions.Aws.Lambda` 1.18.0](https://www.nuget.org/packages/Temporalio.Extensions.Aws.Lambda/1.18.0), [Lambda extension source](https://github.com/temporalio/sdk-dotnet/tree/1.18.0/src/Temporalio.Extensions.Aws.Lambda), [OpenTelemetry extension source](https://github.com/temporalio/sdk-dotnet/tree/1.18.0/src/Temporalio.Extensions.Aws.Lambda.OpenTelemetry), and the [maintained Lambda Worker sample](https://github.com/temporalio/samples-dotnet/tree/6aba4fb9ea08177e303352ec9a4c61e303cefb0e/src/LambdaWorker). Use this reference for .NET SDK-specific package, entry-point, Worker configuration, tuned defaults, observability, and diagnostic details. For shared AWS Lambda deployment, observability infrastructure, and diagnostic flow, see `setup.md`, `observability.md`, and `diagnostics.md`. From b2ab9788a5eef997f403c30d6e95d88870c2772f Mon Sep 17 00:00:00 2001 From: Amir Benvenisti <128422269+starfleeth@users.noreply.github.com> Date: Fri, 4 Sep 2026 08:48:10 -0500 Subject: [PATCH 5/6] Update SKILL.md --- SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SKILL.md b/SKILL.md index 9c825a5..530ff12 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,7 +1,7 @@ --- name: temporal-serverless description: 'Deploy and operate Temporal Workers on serverless compute (AWS Lambda) driven by the Worker Controller Instance (WCI). Use when the user mentions: "serverless worker", "Temporal serverless", "Worker Controller Instance", "WCI", "deploy Temporal worker on Lambda", "Lambda packaging", "Lambda timeout", "WCI inspection", "CloudFormation Temporal".' -version: 0.6.1 +version: 0.6.0 --- # Skill: temporal-serverless From 53da3b577d845c638c82f65b8c365eff116a45c5 Mon Sep 17 00:00:00 2001 From: starfleeth <128422269+starfleeth@users.noreply.github.com> Date: Fri, 4 Sep 2026 08:55:16 -0500 Subject: [PATCH 6/6] Address .NET Lambda review nits --- references/aws-lambda/sdk-dotnet.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/references/aws-lambda/sdk-dotnet.md b/references/aws-lambda/sdk-dotnet.md index 454a968..6cad1af 100644 --- a/references/aws-lambda/sdk-dotnet.md +++ b/references/aws-lambda/sdk-dotnet.md @@ -28,7 +28,7 @@ If sources disagree, use the installed artifact's public API, followed by the ma ## Entry point -**`TemporalLambdaWorker.CreateHandler(version, configure)`** — returns a `Func` that your handler method delegates to. Overloads take either a synchronous `Action` or an asynchronous `Func` for setup that must await. A further overload taking `TemporalLambdaWorkerHandlerOptions` is an internal test seam and is not for production use. +**`TemporalLambdaWorker.CreateHandler(version, configure)`** — returns a `Func` that your handler method delegates to. Overloads take either a synchronous `Action` or an asynchronous `Func` for setup that must await. ## Configure callback @@ -69,7 +69,8 @@ public class LambdaFunction new WorkerDeploymentVersion("my-app", "build-1"), config => { - config.WorkerOptions.TaskQueue = "my-task-queue"; + config.WorkerOptions.TaskQueue = + Environment.GetEnvironmentVariable("TEMPORAL_TASK_QUEUE") ?? "my-task-queue"; config.WorkerOptions .AddWorkflow() .AddActivity(MyActivities.MyActivity);