Support for .NET SDK on the temporal serverless skill - #10
Support for .NET SDK on the temporal serverless skill#10harish-narayanappa-10 wants to merge 10 commits into
Conversation
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) <noreply@anthropic.com>
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) <noreply@anthropic.com>
…temporal-serverless into dotnet-sdk-support
…verless into dotnet-sdk-support
There was a problem hiding this comment.
🟡 Changes recommended
Several new/updated docs lines contain ambiguous placeholders, a copy/paste command that won’t work as written, and a few inconsistencies/typos that can mislead users following the .NET Lambda setup steps.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds first-class documentation support for deploying Temporal .NET Serverless Workers on AWS Lambda, aligning the skill’s guidance and references with the .NET SDK’s Lambda worker package, packaging requirements (RID-specific publish + native bridge), TLS CA bundle behavior, and OpenTelemetry setup.
Changes:
- Extend the skill’s supported SDK list (README + SKILL) to include .NET.
- Add a new .NET SDK section to
references/sdk-configuration.md(package/API entry point, versioning behavior, Lambda defaults, RID publish requirements, TLS CA caveat). - Add .NET guidance to AWS Lambda docs: setup (install/handler/publish/create-function/env vars), observability (OTel package + ADOT layer), and diagnostics.
File summaries
| File | Description |
|---|---|
SKILL.md |
Expands the “scope the task” SDK list to include .NET. |
README.md |
Updates supported SDK list and adds an example prompt for .NET Lambda deploy. |
references/sdk-configuration.md |
Introduces .NET Lambda worker package/API/config/versioning/defaults + RID/tls notes and cross-SDK comparison updates. |
references/aws-lambda/setup.md |
Adds end-to-end .NET setup: install/API inspection, handler pattern, RID publish + zip, create-function example, and required env vars. |
references/aws-lambda/observability.md |
Documents .NET OpenTelemetry package usage and ADOT collector layer setup notes. |
references/aws-lambda/iam.md |
Adds an operational warning about verifying updated invoke policies after CloudFormation updates. |
references/aws-lambda/diagnostics.md |
Adds .NET-specific diagnostics for logging, native bridge packaging, TLS CA loading, and handler format issues. |
Review details
Suppressed comments (1)
references/sdk-configuration.md:242
<provider>/observability.mdis ambiguous in this reference (unlikeSKILL.md, this file doesn't explain placeholder substitution). Use the concrete in-repo path so readers can follow it directly.
OpenTelemetry lives in a **second package**, `Temporalio.Extensions.Aws.Lambda.OpenTelemetry` (also 1.18.0) — unlike Python, where OTel is an extra on the same package. → `<provider>/observability.md`.
- Files reviewed: 7/7 changed files
- Comments generated: 7
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
What
Adds .NET SDK support to the Serverless Workers skill. Previously an agent asked for a .NET Worker had no package name, entry point, packaging steps, or failure signatures to work from.
#Primary Changes
sdk-configuration.md— .NET section, updates to the cross-SDK comparison table.aws-lambda/setup.md— worker codeaws-lambda/diagnostics.md— .NET failure signaturesaws-lambda/observability.md— the separate OpenTelemetry package.SKILL.md,README.md— .NET added to the SDK lists.Two .NET specifics are in the happy path rather than troubleshooting, because
either one silently breaks a first deployment:
publish omits its Linux build and the function fails at first invocation, not at
build time.
SSL_CERT_FILEmust be set on the function. AWS's .NET 8 Lambda imagesoverride it, so the Rust core cannot load system root CAs and the Worker fails
with
NativeCertsNotFound— an error that names certificates but has nothing todo with the API key.
Also documented: .NET's Worker-level default versioning behavior is
AutoUpgradewhere TypeScript's isPINNED.Testing
Deployed a .NET hello-world Worker end to end on Lambda and running a Workflow to completion. The items above came from what was observed.
Docs were fixed separately - temporalio/documentation#5229