azure-functions-durable-python: Activity traces cannot be linked to an Orchestrator

I have an Azure Durable Functions app using Python. It’s a very simple model, where an orchestrator just schedules one activity.

There is some logging going on inside my activity functions, but I’m currently not able to join them to any orchestrator who could have called it.

The tracking data for a single instance can be found using a relatively simple Kusto query, such as:

let targetInstanceId = "ddd1aaa685034059b545eb004b15d4eb";
let start = datetime(2018-03-25T09:20:00);
traces
| where timestamp > start and timestamp < start + 30m
| where customDimensions.Category == "Host.Triggers.DurableTask"
| extend functionName = customDimensions["prop__functionName"]
| extend instanceId = customDimensions["prop__instanceId"]
| extend state = customDimensions["prop__state"]
| extend isReplay = tobool(tolower(customDimensions["prop__isReplay"]))
| extend sequenceNumber = tolong(customDimensions["prop__sequenceNumber"])
| where isReplay != true
| where instanceId == targetInstanceId
| sort by timestamp asc, sequenceNumber asc
| project timestamp, functionName, state, instanceId, sequenceNumber, appName = cloud_RoleName

Although this displays the orchestrator as well as the current activity state, it doesn’t include activity logging from my Python app.

I can find the logging using another simple kusto query:

    let start = datetime(2020-09-23T09:50:00);
    traces
    | where operation_Name == 'NAME_OF_MY_ACTIVITY'
    | where timestamp >= start and timestamp < start + 30m
    | limit 20

This does in fact yield my logging, but doesn’t provide me with any clues to which orchestrator instance this activity “belonged”:

• customDimensions['prop__instanceId'] is empty
• operation_ParentId points to the id inside the requests table
• … which is where the trail ends

So basically I see the two pieces:

1. Orchestrator on the one side, with activity status but without activity logging
2. Activity logging on the other side, without any clues (as far as I can see) how to link this to the accompanying orchestrator

It would be great if these two could be linked together. An example how I expected it to work (but I might be mistaken) is that prop__instanceId is available inside the activity-level traces (or requests) logging as well.