question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Expose version information in the orchestration context

See original GitHub issue

It would be convenient if orchestration instances could know their versions so that developers could write inline branch logic when versioning their orchestrations rather than mapping new versions to new classes, which is a bit more heavy-handed.

This is something supported by Temporal: https://docs.temporal.io/docs/go-versioning/. I think it would be useful to have in DTFx as well, though developers would need to use it carefully.

Example:

    class LongRunningOrchestration : TaskOrchestration<string, string>
    {
        public override async Task<string> RunTask(OrchestrationContext context, string input)
        {
            await context.ScheduleTask<string>(typeof(ActivityA), input);

            // At this point in the orchestration, a change may have been deployed

            if (context.Version == Version1)
            {
                await context.ScheduleTask<object>(typeof(ActivityB1), input);
            }
            else if (context.Version == Version2)
            {
                await context.ScheduleTask<object>(typeof(ActivityB2), input);
            }

            return $"Completed as version '{context.Version}'";
        }
    }

Issue Analytics

  • State:open
  • Created 3 years ago
  • Comments:6

github_iconTop GitHub Comments

1reaction
jviaucommented, Mar 29, 2021

@cgillum thanks! I might open a different issue to discuss this problem and how DTFx could improve upon it.

1reaction
jviaucommented, Mar 29, 2021

I solved this in our codebase by having Name and Version be properties on our base class OrchestrationBase. And then middleware sets it, as the name and version are available there via DispatchMiddlewareContext.GetProperty<OrchestrationRuntimeState>(). Did a similar approach for Activities - just a different property to get from the middleware context.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Bindings for Durable Functions (Azure Functions)
The orchestration trigger binding supports both inputs and outputs. Here are some things to know about input and output handling: inputs -  ......
Read more >
Control the Running Context of an Orchestration
Choose the context to launch and resume an autolaunched orchestration to control the access associated orchestration runs have to Salesforce data. The sel....
Read more >
Azure Durable Functions
OrchestrationClient is responsible for starting/stopping orchestrators and monitoring their status. Orchestrator Function: Defines a stateful workflow in code ...
Read more >
Durable Functions 101 - Tsuyoshi Ushio - Medium
I had the following error while building at first: Version ... public static async Task Run(DurableOrchestrationContext context) { var ...
Read more >
Orchestration Designer using Context Store
Orchestration Designer retrieves data from the context store and updates and/or adds new data in the context. Once Orchestration Designer is added into...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found