IDurableOrchestrationClient.StartNewAsync -- overloads differ in generic constraints.

[Ilia-Kosenkov]

While working with durable orchestrations, I noticed that StartNewAsync<T>(string, T) has a T : class constraint,

azure-functions-durable-extension/src/WebJobs.Extensions.DurableTask/ContextInterfaces/IDurableOrchestrationClient.cs

Lines 142 to 145 in 9af1662

	Task<string> StartNewAsync<T>(
	string orchestratorFunctionName,
	T input)
	where T : class;

but StartNewAsync<T>(string, string, T) has none

azure-functions-durable-extension/src/WebJobs.Extensions.DurableTask/ContextInterfaces/IDurableOrchestrationClient.cs

Line 163 in 9af1662

Task<string> StartNewAsync<T>(string orchestratorFunctionName, string instanceId, T input);

Is there a reason such a difference exists? For instance, IDurableOrchestrationContext.GetInput<T>(), which can be used to obtain said orchestration input, has no such constraint. Furthermore, the documentation states orchestration input should be something JSON-serializable, and since JSON.Net is used, I interpret this as input is anything that can be serialized as JSON, including simple types like int or Guid and custom-derived types (including value-type structs), which clearly violates T : class constraint.

[davidmrdavid]

Thanks for reaching out @Ilia-Kosenkov. This is interesting. It's certainly strange that the generic constraints differ, and I believe it might be just an oversight and that in reality T should not need to be a class in either. However, I can't say that with certainty, so let me reach out to the rest of the team.

@cgillum: are you familiar with this?

[Ilia-Kosenkov]

Revisiting this discussion later, I found this issue here #1814 which highlights the same problem, and I am surprised it has not been resolved (or at least answered) in more than a year.

[davidmrdavid]

Thanks for the ping @Ilia-Kosenkov, I think this fell under our radar. We have not had the chance to discuss this with the team, but given that the change proposed is so simple, I went ahead and optimistically opened a patch PR here. I'll use that to drive the conversation forward.

[Ilia-Kosenkov]

Hey. Thanks for taking a look at this! We use a custom source generator to provide type-safe API for orchestrations, and since we generate calls to StartNewAsync<T>(), we are forced to constraint T : class even though everywhere else we can actually pass any T, including convenient value tuples.