I would like to have the option to not retrieve the Input.Entities[] in the json response when calling the getStatusUri. The reason for this is because we have durable functions that receive large payloads, which is distributed to activity functions using the Fan-Out, Fan-In pattern, and the large Input.Entities[] is rarely required when requesting a status update.
I'm not sure what Input.Entities refers to. Can you elaborate? Is Entities the name of a list payload being used as the input to your orchestrator function?
Hi @cgillum thanks for the reply.
Yes that's right. input.Entities[] is a payload we are sending to the orchestrator function. When we query the statusQueryGetUri the response can be quite large. An example of the response is (entities not included for brevity):
{
"instanceId": "1652390b26e247c394b6f632514b451b",
"runtimeStatus": "Completed",
"input": {
"$type": "Common.Models.Payload, Common.Models",
"Entities": [ ... may contain hundreds of entities ... ]
},
"customStatus": "All Entities were processed successfully",
"output": {
"ActivityResults": [ ]
},
"createdTime": "2018-10-16T07:44:55Z",
"lastUpdatedTime": "2018-10-16T07:45:01Z"
}
We have total control over the customStatus and the output which only displays a list of failed activity results. From what I can see the same control isn't possible with the input nor can you prevent the input data being returned in the json response. Could the API allow the caller to provide a query string param to prevent the input data being returned e.g. showInput, in the same way showHistory and showHistoryOutput works?
Currently I think the only option I have is to create a GetStatus function which can call context.GetStatusAsync(instanceId) and from there I could remove the input from the response.
Thanks for clarifying. I think we could solve this by adding a showInput flag as you suggested. To avoid a breaking change, we'd set it to true by default but callers like you could set it to false to avoid the cost of retrieving this value.
Thanks for adding this issue as an enhancement. Would you have an ETA for this feature?
ETA is a bit hard for features like this because it largely depends on how much help we can get. However, I might have someone who can help relatively soon...
This functionality has been checked-in and will be available in the next release.
Most helpful comment
Thanks for clarifying. I think we could solve this by adding a
showInputflag as you suggested. To avoid a breaking change, we'd set it totrueby default but callers like you could set it tofalseto avoid the cost of retrieving this value.