Adding rewind client API

[bachuv]

Adding the rewind API for the Java SDK.

• Added a new rewindPostUri to HttpManagementPayload
• Introduced rewindInstance API in DurableTaskClient
• Update protobuf definitions
• Added tests and samples

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes are added to the CHANGELOG.md
• I have added all required tests (Unit tests, E2E tests)

[Copilot]

Pull request overview

This pull request adds support for the rewind functionality in the Java SDK for Durable Task Framework. Rewind allows failed orchestrations to be replayed from their last known good state, which is useful for recovering from transient failures.

Changes:

• Added rewindInstance API methods to DurableTaskClient and DurableTaskGrpcClient for rewinding failed orchestrations
• Added rewindPostUri field to HttpManagementPayload to support HTTP-based rewind operations in Azure Functions
• Updated protobuf definitions with ExecutionRewoundEvent and related changes to support the rewind feature

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
client/src/main/java/com/microsoft/durabletask/DurableTaskClient.java	Adds public API methods for rewinding orchestration instances with optional reason parameter
client/src/main/java/com/microsoft/durabletask/DurableTaskGrpcClient.java	Implements rewindInstance by building and sending RewindInstanceRequest via gRPC
azurefunctions/src/main/java/com/microsoft/durabletask/azurefunctions/HttpManagementPayload.java	Adds rewindPostUri field with reason parameter placeholder for HTTP-based rewind operations
samples/src/main/java/io/durabletask/samples/RewindPattern.java	Demonstrates rewind functionality with sample code that fails once then succeeds after rewind
endtoendtests/src/test/java/com/functions/EndToEndTests.java	Adds end-to-end test for rewind functionality and improves test configuration with @BeforeAll setup
endtoendtests/src/main/java/com/functions/RewindTest.java	Implements Azure Functions-based test orchestration that demonstrates the rewind feature
internal/durabletask-protobuf/protos/orchestrator_service.proto	Adds ExecutionRewoundEvent and extends multiple messages with new fields for rewind support
internal/durabletask-protobuf/PROTO_SOURCE_COMMIT_HASH	Updates to reflect the new protobuf source version
CHANGELOG.md	Documents the new rewind client API feature
.github/workflows/build-validation.yml	Increases emulator initialization wait time and adds logging for better CI reliability

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[halspang]

Just a few questions.

[halspang]

So, what happens if someone calls this with DTS instead of a supported backend? Is it a defined behavior that will lead to the orchestration failing? Or would it lead to a non-deterministic state/stuck orchestration?

If it fails the orchestration, I'm fine just having a note here. If it will lead to stuck orchestrations, I wonder if we can find a way to reject/fail it in the worker?

[sophiatev]

So all backends support rewind (including DTS). This is only an issue if someone is trying to use the GrpcDurableTaskClient as a standalone SDK, so not with Functions, in which case it will attempt to call into the sidecar gRPC implementation in DTS which will throw a not supported exception.

Hence this part of the method comment:

The standalone {@code GrpcDurableTaskWorker} does not currently support orchestration processing for rewind.

[bachuv]

It fails with the following error: io.grpc.StatusRuntimeException: UNIMPLEMENTED: The rewind operation is not yet supported.

I was seeing this error in the CI tests when I added durabletask rewind tests which is how I found out that it wasn't supported. Here's a test run where this was happening: https://github.com/microsoft/durabletask-java/actions/runs/21721638553/job/62652715658

[halspang]

As long as it's consistent, I'm OK with the note. The main thing I wanted to avoid was someone accidentally rewinding a valid, in-progress orchestration on an unsupported backend and having it get in a weird stuck state. If that's not the case, I'm good with this :)