[Bernd Verst (berndverst)]

Motivation

Provider/backend completion failures can replace an orchestration's requested outcome without reaching host failure telemetry or lifecycle notifications. Empty completion acknowledgements cannot communicate that server-adjusted outcome. This additive protocol contract supports the scenario tracked by Azure/azure-functions-durable-extension#3569.

Changes

• Add optional CompleteOrchestrationWorkItemRequest.providerFailure at field 14 for explicit infrastructure-failure provenance, separate from ordinary application failures.
• Add optional CompleteOrchestrationWorkItemResponse.outcome at field 1, carrying accepted instance/execution/function correlation, a stable token-free completion identity, the actual accepted status, and optional validated provider/backend failure diagnostics.
• Reuse the existing extended-session CompleteInstanceWorkItemResponse.orchestratorResponse envelope, so the initial streaming ACK carries the same outcome without changing RPCs or streaming field numbers.
• Document payload-safe diagnostics, size-limit scopes (CompletionRequest, ExternalizedPayload, BackendValidation), acceptance semantics, and legacy interoperability.
• Add six Java protocol tests covering empty ACKs, unary/streaming round trips, explicit failure provenance, optional diagnostic presence and numeric limits, nonterminal outcomes, and legacy readers preserving unknown fields.

Compatibility and scope

All existing fields, enums, options, and RPC shapes are unchanged. Old clients ignore the additions; old servers may return empty ACKs. Missing outcomes, including later streaming health-ping ACKs, are not authoritative. Unaccepted/stale completions must not fabricate outcomes. Provenance is diagnostic metadata, not an authorization decision; implementations must validate and sanitize it rather than echoing caller-provided content. Both peers need contract support to report authoritative outcomes. Completion identities aid deduplication but do not guarantee durable notification delivery. This PR defines the protocol only; provider/backend and host behavior require coordinated implementation changes.

Validation

• lib\java\gradlew.bat -p lib\java build --console=plain --quiet --no-daemon with JDK 11: passed, including protobuf/gRPC generation, Java compilation, and 6 tests (0 failures/errors/skips).
• Compiled current and base-commit descriptors with repository-pinned protoc 3.12.0; comparison of 9 file descriptors confirmed that the only structural additions are the two new messages and fields 14/1. Existing messages, enums, fields, options, and RPCs compare identically.
• git diff --check: passed.

The existing Gradle 7.0.2 wrapper cannot run with the environment's default Java 21; validation used a compatible JDK 11 without changing repository build configuration.