Reading TaskOrchestrationContext in middleware throws InvalidOperationException

[stevendarby]

Minimal repro of middleware:

internal sealed class MyMiddleware : IFunctionsWorkerMiddleware
{
    public async Task Invoke(FunctionContext context, FunctionExecutionDelegate next)
    {
        if (await GetInputValueAsync<TaskOrchestrationContext>(context) is { } orchestrationContext)
        {
            // Do stuff
        }

        await next.Invoke(context);
    }

    public static async Task<T?> GetInputValueAsync<T>(FunctionContext context)
    {
        foreach (var bindingMetadata in context.FunctionDefinition.InputBindings.Values)
        {
            var functionParameter = context.FunctionDefinition.Parameters.FirstOrDefault(parameter => parameter.Name == bindingMetadata.Name && parameter.Type.IsAssignableTo(typeof(T)));
            if (functionParameter != null)
            {
                return (await context.BindInputAsync<T>(bindingMetadata)).Value;
            }
        }

        return default;
    }
}

I have middleware which tries reading function inputs as TaskOrchestrationContext so that it can then read its input and set a correlation context based on the input content. This used to work until I recently updated packages, now I get: System.InvalidOperationException: 'Orchestration history state was either missing from the input or not a string value.'

Is there a workaround? Thanks

[stevendarby]

More info:

The (await context.BindInputAsync<T>(bindingMetadata)).Value is actually null, i.e. binding was unsuccessful. The exception then happens later.

I think this is partially related to this old issue I raised: Azure/azure-functions-dotnet-worker#2332

For whatever reason, BindInputAsync<TaskOrchestrationContext>(bindingMetadata) doesn't work anymore and returns a null value. This is the primary issue to solve. Then the knock on effect is that the null is cached against bindingMetadata, so when your own internal code tries to bind it, it's getting that cached null.

[stevendarby]

I found a temporary (I hope) workaround which is to bind it to a string instead. This returns a base64 encoded string which, once decoded, contains a JSON representation of the input message. Because this is among other, non-JSON data, I can't straightforwardly deserialize this string as JSON, so I am using regex to scan for the particular property I needed, e.g.:

var bytes = Convert.FromBase64String(orchestrationContextString);
var decoded = Encoding.UTF8.GetString(bytes);
var match = Regex.Match(decoded, "\"CorrelationId\"\\s*:\\s*\"([a-zA-Z0-9-]{32,36})\"", RegexOptions.IgnoreCase);
if (match.Success)
{
    var correlationId = Guid.Parse(match.Groups[1].Value);
}

If there is a better way to handle the string, please let me know. If there are breaking change notes about this, please let me know. Unfortunately I'm finding the story around function middleware is not great.

[jviau]

@stevendarby input binding for orchestrations has moved to the end of the middleware due to it negatively impacting async context. It is unrelated to Azure/azure-functions-dotnet-worker#2332.

Unfortunately, I do not think this will be reverted as it fundamentally broke async work inside middleware (it hijacked the middleware execution and broke a lot of stuff). I also don't see a common hook for you to run after the binding is performed now and before your orchestration runs.

Durable will need to refactor to decouple context binding and execution. It is possible, but will be some work on durables end.

[stevendarby]

@jviau thanks for the reply.

If you see my workaround in my last post, what I was hoping for in the short term is a bit of guidance on whether I can do something more robust with that string. Are there any public helpers for constructing the orchestration object from it? Or just the serialised input from within? If not, could that be something you expose without relying on bigger changes from the durable tasks framework?