Logging or Exceptions when Durable Functions Activity Does Not Exist

[tyler555g]

Pretty simple request, but not sure how simple it would be to implement.

Basically I would like some sort of feedback when you use the call_activity() method of the DurableOrchestrationContext class with a Durable Function Activity that does not exist.

import azure.functions as func
import azure.durable_functions as df

def orchestrator_function(context: df.DurableOrchestrationContext):
    logging.info("Starting Activity!")
    result = yield context.call_activity("I_Do_Not_Exist", None, None)
    logging.info("You will never see me because the code stops at the above step!")
    return result

main = df.Orchestrator.create(orchestrator_function)

Side note: I may or may not have spent an hour and a half troubleshooting an orchestrator only to realize it was a typo in the activity name.

[wallflower762]

+1 to this. I too spent a good hour troubleshooting an orchestrator only to find a typo.

[ConnorMcMahon]

We have plans on the extension to explicitly fail orchestrations when messages of no-longer existing (or in this case never existing) activities/orchestrations are hit. This should make detection a bit easier at runtime.

This is something that we could theoretically try catching with a linter (we do something similar with Roslyn Analyzers for .NET), but at this time we don't have a ton of capacity for a linter project like we have for C#.

[davidmrdavid]

Thanks for this feature request! I completely agree with this, it would be great to be able to warn users about typos in activity names as well as identifying "unreachable"/never-called activities. Like Connor said, there are long term plans to work on this and I'm personally really excited about being able to warn users about anti-patterns and to teach best practices via some durable functions-aware linter / analyzer for Python.

In the meantime though, if anyone wanted to hack a quick PR to try to do this specific detection task in an ad-hoc way, I'd be happy to give it a look and consider it for merging.

I imagine two requirements towards this feature:
(1) Obtaining a list of activity names. These can be easily generated by looking at the project's file structure, since their names are simply directory names. This is probably the easy part.

(2) Obtaining all activity references in the orchestration API calls: This is the tricky bit. The right way to approach this is, in my opinion, to use a python parser and to obtain all function calls as a flat list. Then, you can filter by APIs that call activities and find+evaluate the parameter corresponding to the Function name. You do this for all activity-calling APIs. Then you can simply calculate the set difference between the called activities, and the full list of activities you obtained in requirement (1)!

In any case, this could be done within the SDK itself, but it would also be interesting to see if this can be implemented as a VSCode plugin, which should make code parsing easier, and assist in providing live feedback. As I mentioned, I currently do not have the capacity to work on this but, if anyone wanted to give it a try, even just for a small prototype, I'd be happy to give it a look! 🔥

[lilyjma]

Hi @wallflower762, @tyler555g - thank you for using Durable Functions! I'm a PM working on DF and would love to learn about your experience using the product. You can share your feedback in this quick survey to help influence what the team works on next. If you're building intelligent apps, there's also an opportunity to participate in a compensated UX study. Thanks!