* Add .NET reference files for temporal-developer skill Created 11 .NET reference files covering: dotnet.md (overview/quick start), patterns.md, determinism.md, determinism-protection.md, error-handling.md, testing.md, versioning.md, observability.md, data-handling.md, gotchas.md, and advanced-features.md. Follows Python/TypeScript patterns with .NET-specific content for Task determinism, CancellationToken, dependency injection, etc. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix .NET alignment issues from self-review - dotnet.md: Reduce Determinism Rules section to brief cross-reference (was duplicating determinism.md content) - patterns.md: Add ParentClosePolicy to Child Workflows example - gotchas.md: Add missing "Heartbeat Timeout Too Short" subsection - versioning.md: Add missing Key Concepts, Deployment Strategies, Query Filters, PINNED/AUTO_UPGRADE guidance, CLI examples - advanced-features.md: Add worker-level heading for exception types Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix .NET correctness issues from verification pass - patterns.md: Fix cancellation pattern to use official TemporalException.IsCanceledException(e) with detached CancellationTokenSource - advanced-features.md: Fix DI hosting example to use official AddHostedTemporalWorker(clientTargetHost:, clientNamespace:, taskQueue:) pattern Verified against official SDK README, API docs, and temporal-docs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Update supported language references to include .NET - SKILL.md: Add "Temporal .NET" and "Temporal C#" trigger phrases, update overview to mention .NET, add .NET entry in getting started - core/determinism.md: Add .NET entry in SDK Protection Mechanisms Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Edits to advanced features * edits to determinism protection, and move the .editorconfig section * missed one * edit determinism.md * edit error-handling.md * edit gotchas.md * edit patterns.md * edit versioning.md * edit observability.md * fix metrics * self-review round 1 * minor correctness fixed * Update references/dotnet/patterns.md Co-authored-by: Justin Anderson <44687433+jmaeagle99@users.noreply.github.com> * address comments, clarify reference to earlier code snippet * clarify that operations are forbidden IN WORKFLOWS * cleanup workflow cancellation handling example * add task token retrieval comment * update .net requirements * Fix propagation of workflow cancellation --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Justin Anderson <44687433+jmaeagle99@users.noreply.github.com>
5.7 KiB
Java SDK Advanced Features
Schedules
Create recurring workflow executions.
import io.temporal.client.schedules.*;
ScheduleClient scheduleClient = ScheduleClient.newInstance(service);
// Create a schedule
String scheduleId = "daily-report";
ScheduleHandle handle = scheduleClient.createSchedule(
scheduleId,
Schedule.newBuilder()
.setAction(
ScheduleActionStartWorkflow.newBuilder()
.setWorkflowType(DailyReportWorkflow.class)
.setOptions(
WorkflowOptions.newBuilder()
.setWorkflowId("daily-report")
.setTaskQueue("reports")
.build()
)
.build()
)
.setSpec(
ScheduleSpec.newBuilder()
.setIntervals(
List.of(new ScheduleIntervalSpec(Duration.ofDays(1)))
)
.build()
)
.build(),
ScheduleOptions.newBuilder().build()
);
// Manage schedules
ScheduleHandle scheduleHandle = scheduleClient.getHandle(scheduleId);
scheduleHandle.pause("Maintenance window");
scheduleHandle.unpause();
scheduleHandle.trigger(); // Run immediately
scheduleHandle.delete();
Async Activity Completion
For activities that complete asynchronously (e.g., human tasks, external callbacks). If you configure a heartbeat timeout on this activity, the external completer is responsible for sending heartbeats via the async handle.
Note: If the external system can reliably Signal back with the result and doesn't need to Heartbeat or receive Cancellation, consider using signals instead.
public class ApprovalActivitiesImpl implements ApprovalActivities {
@Override
public String requestApproval(String requestId) {
ActivityExecutionContext ctx = Activity.getExecutionContext();
// Get task token for async completion
byte[] taskToken = ctx.getTaskToken();
// Store task token for later completion (e.g., in database)
storeTaskToken(requestId, taskToken);
// Mark this activity as waiting for external completion
ctx.doNotCompleteOnReturn();
return null; // Return value is ignored
}
}
// Later, complete the activity from another process
public void completeApproval(String requestId, boolean approved) {
WorkflowServiceStubs service = WorkflowServiceStubs.newLocalServiceStubs();
WorkflowClient client = WorkflowClient.newInstance(service);
ActivityCompletionClient completionClient = client.newActivityCompletionClient();
// Retrieve the task token from external storage (e.g., database)
byte[] taskToken = getTaskToken(requestId);
if (approved) {
completionClient.complete(taskToken, "approved");
} else {
completionClient.completeExceptionally(
taskToken,
new RuntimeException("Rejected")
);
}
}
Worker Tuning
Configure worker performance settings.
WorkerOptions workerOptions = WorkerOptions.newBuilder()
// Max concurrent workflow task executions (default: 200)
.setMaxConcurrentWorkflowTaskExecutionSize(200)
// Max concurrent activity executions (default: 200)
.setMaxConcurrentActivityExecutionSize(200)
// Max concurrent local activity executions (default: 200)
.setMaxConcurrentLocalActivityExecutionSize(200)
// Max workflow task pollers (default: 5)
.setMaxConcurrentWorkflowTaskPollers(5)
// Max activity task pollers (default: 5)
.setMaxConcurrentActivityTaskPollers(5)
.build();
WorkerFactory factory = WorkerFactory.newInstance(client);
Worker worker = factory.newWorker("my-queue", workerOptions);
worker.registerWorkflowImplementationTypes(MyWorkflowImpl.class);
worker.registerActivitiesImplementations(new MyActivitiesImpl());
factory.start();
Workflow Failure Exception Types
Control which exceptions cause workflow failures vs workflow task failures.
By default, only ApplicationFailure (and its subclasses) fail the workflow execution. All other exceptions fail the workflow task, causing the task to retry indefinitely until the code is fixed or the workflow is terminated.
Per-Workflow Configuration
Use WorkflowImplementationOptions to specify which exception types should fail the workflow:
Worker worker = factory.newWorker("my-queue");
worker.registerWorkflowImplementationTypes(
WorkflowImplementationOptions.newBuilder()
.setFailWorkflowExceptionTypes(
IllegalArgumentException.class,
CustomBusinessException.class
)
.build(),
MyWorkflowImpl.class
);
With this configuration, IllegalArgumentException and CustomBusinessException thrown from the workflow will fail the workflow execution instead of just the workflow task.
Worker-Level Configuration
Apply to all workflows registered on the worker:
WorkerFactoryOptions factoryOptions = WorkerFactoryOptions.newBuilder()
.setWorkflowHostLocalTaskQueueScheduleToStartTimeout(Duration.ofSeconds(10))
.build();
WorkerFactory factory = WorkerFactory.newInstance(client, factoryOptions);
Worker worker = factory.newWorker("my-queue");
// Register each workflow type with its own failure exception types
worker.registerWorkflowImplementationTypes(
WorkflowImplementationOptions.newBuilder()
.setFailWorkflowExceptionTypes(
IllegalArgumentException.class,
CustomBusinessException.class
)
.build(),
MyWorkflowImpl.class,
AnotherWorkflowImpl.class
);
- Tip for testing: Set
setFailWorkflowExceptionTypes(Throwable.class)so any unhandled exception fails the workflow immediately rather than retrying the workflow task forever. This surfaces bugs faster.