Explicit taskHub parameter for stored procedures about durabletask-mssql

[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).

[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]

@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.

[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