RaiseEventAsync with a given taskhubname is missing compared to in process

[jcageman]

In the non isolated worker model you could trigger an orchestration instance from a different taskhub like so:

Task RaiseEventAsync(string taskHubName, string instanceId, string eventName, object eventData, string connectionName = null);
See: https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.webjobs.durableorchestrationclientbase.raiseeventasync?view=azure-dotnet-legacy#microsoft-azure-webjobs-durableorchestrationclientbase-raiseeventasync(system-string-system-string-system-string-system-object-system-string)

I currently don't see any way to do that currently. Also an option to create a new DurableTaskClient dynamically for a different taskhub is not trivial as far as I can see?

    [Function(nameof(WebhookHttpTrigger))]
    public async Task<HttpResponseMessage> RunAsync([HttpTrigger(AuthorizationLevel.Anonymous, "POST", Route = "MyWebhook/{taskHubName}/{orchestrationId}/{requestId}")] HttpRequestMessage req,
        [DurableClient] DurableTaskClient client,
        string taskHubName,
        ILogger logger)

I would like to create a DurableClient with the taskHubName parameter given in the http route or RaiseEventAsync with a taskhubname as we could do in the non-isolated case. As far as i can find the only option is building a custom binder? Using binder as in Azure/azure-functions-dotnet-worker#1106 (comment) is also not possible in isolated.

[jviau]

@jcageman can you try getting a client with the name provided:

[DurableClient(TaskHub = "hubname")]

[jcageman]

@jcageman can you try getting a client with the name provided:

[DurableClient(TaskHub = "hubname")]

as you can see in the example the name of the hub is coming from the http call itself, hence i cannot hardcode the hubname, i need to use the query parameter. The only workaround i see is putting this message on a queue per taskhub and let every taskhub read from it's own queue.

[jviau]

Ah I see. Unfortunately, we won't be adding that overload you are asking for. Instead, we will need to evaluate a way to allow dynamically retrieving a client for the requested task-hub.

[jcageman]

That sounds fine as well!