Explicit taskHub parameter for stored procedures

[michaelplavnik]

Please consider changing approach from using implicit dt.CurrentTaskHub() to explicit parameter in all procedures.

Rational. Flexibility in support database sharing/isolation approaches and simplicity.

For example, from documentation: "This is often valuable when your organization has many small apps but prefers to manage only a single backend database. When multitenancy is enabled, different apps connect to a shared database using different database login credentials and each app will only have access to its own data." Explicit assumption of different login is not flexible, and might be not reflecting reality for majority of financial organizations that actually want to share the database schema.

[cgillum]

@michaelplavnik can you share more about the setup that you want to enable? There are several ways to share a database and I want to understand if there is a mechanism to enable your scenario that doesn't require explicit task hub parameters.

I anticipate it will be difficult for us to continue support the higher security model if we add explicit task hub parameters.

[michaelplavnik]

The following setup: hub process is running under AD account, SQL server trusted authentication, shared connection pool between task hub and domain specific logic. Multiple physical hosts, each running single hub process. Hosts are partitioned based on task hub name.

In regards to your concern. It seems to revolve around @taskHubMode = 1. This can still be enforced even with explicit task hub name (e.g. instead of deducing task hub name, assert USER_NAME() = taskHubName). Other mode then becomes application level responsibility mode.

[cgillum]

I see. I think that strategy might work and that the feature could be generally useful - thank you.

While useful, it may be difficult for our team to prioritize this feature at this time without input from more users. That said, many of the features in this project are community contributions, and we'd be happy to accept a PR for this enhancement as well is anyone wants to contribute it (in which case we can publish it immediately).

[vigouredelaruse]

i support this line of discussion because operating durable functions with the sql provider drives one into conflict with unforable combinations of at minimum

• 1:1 map of sql-login-name<=> task hub separation. in a dev environment with frequent code changes this is a confounding factor for retiring in-flight orchestrations that encourages bloat of 'abandoned' schemas and databases with inflight orchestrations
• tight coupling of schema names and kubernetes func deploy configuration of scalar metric as per the config below. this is a cross-cutting concern that depends on the keda autoscaler configuration

  - metadata:
      connectionStringFromEnv: FunctionStorage_SQLSERVER
      query: SELECT dt.GetScaleRecommendation(10, 1)
      targetValue: '1'
    type: mssql

to expand on scale recommendations for a minute the issue seems be solvable by parameterizing the query clause in the above exhibit to abstract away the schema name placeholder as per

but that's not a simple matter of search and replace here https://github.com/microsoft/durabletask-mssql/blob/main/src/DurableTask.SqlServer/Scripts/logic.sql

instead the achievable use case i seem to be reaching for is an extension of earlier points in this msg with at minimum

• environment independent platform support for retiring inflight orchestrations

i believe the rationale posited by the original poster is in line with what i've said here. apologies if not