Files
Donald Pinckney 44eba4e91c Add .NET SDK support to temporal-developer skill (#39)
* 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>
2026-04-17 14:28:02 -04:00

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.