Cohesive.Adapters.DurableTask 0.1.0-alpha.147

Cohesive.Adapters.DurableTask

Cohesive.Adapters.DurableTask executes an explicitly bounded canonical Process profile on Azure Durable Task and provides monitoring projections for current and migrated historical task hubs.

Install

dotnet add package Cohesive.Adapters.DurableTask

Check a Process realization

Planning consumes the exact canonical Process plan and returns either a complete target realization or structured diagnostics:

var result = DurableTaskProcessRealizationCompiler.Compile(compiledProcessPlan);

if (!result.IsSuccessful)
{
    foreach (var diagnostic in result.Realization.Diagnostics)
        Console.Error.WriteLine($"{diagnostic.Code}: {diagnostic.Message}");

    return;
}

DurableTaskProcessRealizationPlan plan = result.Plan!;

The physical orchestration retains CompiledProcessPlan and ProcessReferenceInterpreter as semantic authority. Durable Task owns scheduling, deterministic replay, activities, sub-orchestrations, timers, and provider history.

Implemented profile

The executable slice covers Transition and Relation/query operations, bound Requests, durable after-origin domain events, Choice, Match, bounded Fork/Join, AwaitMatch, Timer, Process-token Signals, child Processes, bounded partitioning and recurrence, durable cuts, Return, and Fail.

The adapter also provides:

• Canonical start admission and exact replay.
• Safe Process status, trace, and explain projections.
• Separate authority-scoped retrieval of retained canonical input and terminal values.
• Lifecycle control across Continue-as-new.
• Current standalone-SDK monitoring repositories.
• A migration-only reader for hubs created by the retired Core adapter.
• Differential and Scheduler-emulator conformance coverage.

Important boundaries

The executable profile is narrower than the planning profile. Reply emission nodes, non-Process Signal targets, activation-local Signal delivery, lifecycle Signal qualification, atomic-with-origin event publication, and complete provider cleanup/recovery semantics remain unavailable and fail closed.

Scheduler custom status and history are physical evidence, not a replacement Process definition, continuation, inbox, outbox, or semantic trace. Potentially sensitive input and terminal values are available only through the separate trusted value repository and never enter generic monitoring records.

The migration reader does not fabricate canonical evidence that historical runs did not retain.

Telemetry

The Process execution repository emits native .NET activities and metrics from Cohesive.Adapters.DurableTask.ProcessExecutionRepository. Register the package-owned scopes directly with the host's OpenTelemetry pipeline:

tracing.AddSource(DurableTaskProcessExecutionRepositoryTelemetry.ActivitySourceName);
metrics.AddMeter(DurableTaskProcessExecutionRepositoryTelemetry.MeterName);

One repository query produces a parent query activity plus separate provider-read and Cohesive-projection children. The cohesive.durable_task.process_execution.query.duration histogram exposes the same split through its bounded cohesive.durable_task.query.phase dimension. Provider and returned item-count histograms help distinguish page size from provider latency without exporting task hubs, continuation tokens, Process identities, definitions, or payloads.

This adapter scope is intentionally not part of AddCohesiveInstrumentation: applications opt into the providers they actually use by registering their package constants.

Observational read retry progress

process.PointRead(entity, key, policy: ...) remains a canonical Relation/Query node. A policy demanding ProcessReadProgress.Durable is realized by orchestration history: each classified failed attempt is a retained activity result, backoff is a durable timer, and every activity receives the original absolute deadline. A worker restart replays completed results and timers without resetting the logical attempt budget. There is no new retry store. No-policy reads preserve their existing activity path.

A queued activity checks the deadline before calling its host. Running reads use cooperative cancellation and wait for host quiescence; worker shutdown propagates for scheduler redelivery. An unrecorded activity completion may cause another physical read, so this does not promise exactly-once database access. Only explicitly selected structured failures retry; exceptions are not classified automatically. Deadline exhaustion becomes a sanitized processes.read.deadlineExceeded operation failure. Retained observations remain subject to existing history payload protection and retention policies.

Tests simulate history replay after interruption, verify deadlines and attempt exhaustion, and exercise the canonical interpreter and activity boundary. They do not establish live scheduler restart qualification.

Continue

• Internals contains monitoring, trusted value retrieval, planning, worker registration, execution, suspension, recovery, validation, and the full capability boundary.
• Durable Task interpreter decision records the accepted architecture.
• Cohesive.Processes owns canonical Process semantics.
• Cohesive.Storage provides the separate provider-neutral durable Process runtime and store port.