API to restart an orchestration instance

[akshaykumars10]

The HTTP URL for restarting an orchestration instance: restartPostUri
We use Eternal orchestrators in our use case. In the case of any failures that we can recover from, We would like to restart the orchestration instance. However, the restart API is not available in the Java SDK. Can we please prioritize the same?
cc: @cgillum @ChrisRomp

[kaibocai]

Hi @cgillum, do we have this support in durable extension? Thanks.

[ChrisRomp]

@akshaykumars10 are you looking to terminate and restart with the same parameters?

HTTP API reference: https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-http-api

[akshaykumars10]

@ChrisRomp I think we have different parameters to terminate and restart in other SDKs.
Here is a sample response when we create an instance in python:

{
    "id": "b37bf1c100634f699d03d36a1855d6f8",
    "statusQueryGetUri": "http://va7intdurablecls1.azurewebsites.net/runtime/webhooks/durabletask/instances/b37bf1c100634f699d03d36a1855d6f8?taskHub=**",
    "sendEventPostUri": "http://va7intdurablecls1.azurewebsites.net/runtime/webhooks/durabletask/instances/b37bf1c100634f699d03d36a1855d6f8/raiseEvent/{eventName}?taskHub=**",
    "terminatePostUri": "http://va7intdurablecls1.azurewebsites.net/runtime/webhooks/durabletask/instances/b37bf1c100634f699d03d36a1855d6f8/terminate?reason={text}&taskHub=**",
    "rewindPostUri": "http://va7intdurablecls1.azurewebsites.net/runtime/webhooks/durabletask/instances/b37bf1c100634f699d03d36a1855d6f8/rewind?reason={text}&taskHub=**",
    "purgeHistoryDeleteUri": "http://va7intdurablecls1.azurewebsites.net/runtime/webhooks/durabletask/instances/b37bf1c100634f699d03d36a1855d6f8?taskHub=**",
    "restartPostUri": "http://va7intdurablecls1.azurewebsites.net/runtime/webhooks/durabletask/instances/b37bf1c100634f699d03d36a1855d6f8/restart?taskHub=**",
    "suspendPostUri": "http://va7intdurablecls1.azurewebsites.net/runtime/webhooks/durabletask/instances/b37bf1c100634f699d03d36a1855d6f8/suspend?reason={text}&taskHub=**",
    "resumePostUri": "http://va7intdurablecls1.azurewebsites.net/runtime/webhooks/durabletask/instances/b37bf1c100634f699d03d36a1855d6f8/resume?reason={text}&taskHub=**"
}

[cgillum]

@kamperiadis I think this is another case where we can implement the feature entirely in the Java SDK. You should be able to follow this .NET implementation as the guide. Something like this:

@Override
public String reset(String instanceId /*, more params */) {
    OrchestrationMetadata metadata = this.getInstanceMetadata(instanceId, false);
    if (!metadata.isInstanceFound()) {
        // Throw...
    }

    NewOrchestrationInstanceOptions options = ...
    return this.scheduleNewOrchestrationInstance(metadata.getName(), options);
}

[kaibocai]

@akshaykumars10, we have just released java sdk v1.2.0 and this feature is ready to be used. Please try out it. Thanks.

[akshaykumars10]

@kaibocai, I am able to the restart API. Thanks!
I just had one question. I have an orchestrator instance with some custom instance id. When I try to restart that I get a different instance id in the response. is this expected? My expectation from the restart is that it should restart the same instance.
You can see in the screenshot below that on restarting an instance with custom id: akshayyyyyyjj, I get a different new id in the response:

[davidmrdavid]

It would also be my expectation that the restart API would preserve the instanceId, but I'm not sure if this is defined behavior. It would be good to test what happens in .NET in-process with this API, for the sake of reviewing the precedent set there.

[davidmrdavid]

I just tested the restart HTTP API with a DF in-process .NET app and the instanceID seems to be re-generated every time, even when the instanceID was originally user-provided.

Strictly speaking, I think this means there's precedent to keep the behavior as-is. But personally speaking, I do find it to be unintuitive.

[lilyjma]

thanks @davidmrdavid for looking into this.

@akshaykumars10 - looks like this is the expected (albeit unintuitive) behavior. Is it required that the instance IDs stay the same for you or were you just looking to confirm what the behavior is?