Sub-orchestration SetCustomStatus

Is it possible to have a sub-orchestration set SetCustomStatus for the parent orchestration? My situation is as follows:

I have a long running Activity - this activity may actually eventually kick off an Azure Container Instance or something, but for now it runs inside an Activity function and can take a while. The long running code itself already has hooks for monitoring, but I can’t seem to get SetCustomStatus to work how I want.

The important code is as follows (some functions/code omitted for brevity):

        [FunctionName(RunOrchestratorFunctionName)]
        public static async Task<BatchProcessorResult> RunOrchestratorAsync(
            [OrchestrationTrigger] DurableOrchestrationContext context)
        {
            var configuration = context.GetInput<DurableImportConfiguration>();

            var importTask = context.CallSubOrchestratorAsync<BatchProcessorResult>(RunImportOrchestratorFunctionName, configuration);
            var monitorTask = context.CallSubOrchestratorAsync(RunMonitorOrchestratorFunctionName, context.InstanceId + ":Monitor", configuration);
            
            await Task.WhenAll(importTask, monitorTask);

            return await importTask;
        }

        [FunctionName(RunMonitorOrchestratorFunctionName)]
        public static async Task RunMonitorOrchestratorAsync(
            [OrchestrationTrigger] DurableOrchestrationContext context)
        {
            var batchImportStatusMessage = await context.WaitForExternalEvent<BatchImportStatusMessage>(BatchImportStatusChangedEventName);

            context.SetCustomStatus(batchImportStatusMessage);
            
            if (batchImportStatusMessage.MaxTicks != batchImportStatusMessage.CurrentTick)
            {
                context.ContinueAsNew(null);
            }
        }

        [FunctionName(BatchImportStatusFunctionName)]
        public static async Task BatchImportStatusChangedAsync(
            [QueueTrigger(BatchImportStatusRepository.QueueName)] BatchImportStatusMessage message,
            [OrchestrationClient] DurableOrchestrationClient client)
        {
            await client.RaiseEventAsync(message.InstanceId, BatchImportStatusChangedEventName, message);
        }

The long-running process updates a queue, which causes BatchImportStatusChangedAsync to raise an event, which is picked up in RunMonitorOrchestratorAsync, which sets the custom status. However, its setting the custom status on the sub-orchestrator context, not the main orchestrator context.

Is there a clean way to do what I’m doing within the confines of how this long-running process already works?

[ConnorMcMahon]

This seems like a scenario that could be solved with Durable Entities. Just spin up a new entity for each parent orchestration, and the sub orchestrations can update the entity state.

[muratboduroglu]

In orchestrations with a large number of activity steps, we are required to segment the steps into sub-orchestrators for performance reasons. Let’s says an orchestrator with 2000 activities will be loading the history data for all those activities into memory during each replay, compared to segmenting them into suborchestrators for each 100 activities in which case the parent orchestrator will only replay the results of suborchestrators.

In this scenario, suborchesrators are really part of the parent orchesrator and I have a similar case of requiring access to parent’s custom status column, both to write and to read.

1. It would be great to be able to set the custom status for an instance Id, (in this case parents).

2. It would be great to be able to read the custom status while inside the orchestrator code. The DurableOrchestrationClient has the GetStatusAsync call but currently DurableOrchestrationContext only allows you to write the custom status. There is an internal function GetSerializedCustomStatus(), but it’s internal, not used by any other method, and it returns the serialized value instead of calling deserializer.

Obviously the context should not be able to update a different context’s data (parent’s) but I wonder if there is another elegant way to handle this other than using our own storage table for parent-child relationship.

Also this gets little bit more complicated when a suborchestrator also spawns another suborchestrator.