Custom Task Hub name is ignored

[scale-tone]

Here is my host.json:

{
    "version": "2.0",
    "extensions": {
        "http": {
            "routePrefix": "tino"
        },
        "durableTask": {
            "hubName": "VerySpecialTaskHub",
            "storageProvider": {
                "type": "mssql",
                "connectionStringName": "SqlConnectionString",
                "taskEventLockTimeout": "00:02:00"
            }
        }
    }
}

And yet still everything goes into the default 'dbo' task hub:

, and VerySpecialTaskHub never gets created.

What am I doing wrong?

[usemam]

Hi @scale-tone , Which package are you using in your sample - Microsoft.DurableTask.SqlServer.AzureFunctions or Microsoft.DurableTask.SqlServer? And what version?

[scale-tone]

@usemam , I was following these instructions, so it is Microsoft.DurableTask.SqlServer.AzureFunctions, and its latest version - 0.9.0-beta. Code is here, btw.

[bhugot]

same for me

[usemam]

@scale-tone @bhugot As a work-around you can define "taskHubName" property inside "storageProvider" object in your host.json file. Like this:

{
    "version": "2.0",
    "extensions": {
        "http": {
            "routePrefix": "tino"
        },
        "durableTask": {
            "hubName": "VerySpecialTaskHub",
            "storageProvider": {
                "type": "mssql",
                "taskHubName": "VerySpecialTaskHub",
                "connectionStringName": "SqlConnectionString",
                "taskEventLockTimeout": "00:02:00"
            }
        }
    }
}

@cgillum Could you please confirm if this configuration issue is a bug?

[cgillum]

Sorry for missing this discussion. What you're seeing is by design, currently. More details here: https://microsoft.github.io/durabletask-mssql/#/taskhubs?id=configuring-task-hub-names. Long-story short, the default configuration of the SQL backend infers the task hub name from the SQL login username, though you can change this by changing a [setting in the database. More information on the rationale can be found in the Multitenancy documentation topic.

Let me know if you have any questions about this. It's one aspect of the SQL provider's design that breaks from conventions, and I'm curious to see how it works or doesn't work for various scenarios. :)

[scale-tone]

Thanks @cgillum , that explains it. I must have misread the documentation, didn't realize that automatic inference overshadows host.json settings.

But would't it make more sense to do it vice-versa, aka to prefer host.json's hubName over automatic inference? That would at least be consistent with the default storage provider's behavior...

[cgillum]

Yes, using host.json by default would have been more consistent. I tried this in an earlier version but unfortunately ran into a number of experience problems for non-Azure Functions clients (KEDA, SQL Server Management Studio, etc.) since there’s no way to specify a task hub name there. The SQL provider is unique in that we’re trying to promote integration with 3rd party tools and apps, and that unfortunately makes things like task hubs a bit more complicated. Defaulting to user credentials made the setup much simpler for several of these experiences.

BTW, I added a note in the getting started guide just now to mention this behavior.