host.json file not resolved correctly
Kobudzik opened this issue · comments
Hi there!
Today we noticed a strange problem regarding DFM- it couldn't resolve any task hub name. After digging into code, mostly in
DurableFunctionsMonitor/durablefunctionsmonitor.dotnetbackend/Common/Auth.cs I found out DFM resolves task hub names from:
- DFM_HUB_NAME environmental variable, which is null for us,
- as the last resort it gathers task hub names from the database, but in our case db was empty,
- before the last resort solution it tries to check host.json, but this file is not resolved correctly.
host.json is resolved in Auth.cs file. The code first resolves the assembly location and then converts it to functionAppFolder path.
For our case, assembly location gets resolved to: /home/site/wwwroot/ReportManager.dll, which looks correct.
Then this code is executed:
functionAppFolder gets resolved to /home/site which is not correct, and should be /home/site/wwwroot, where host.json is located.
After moving host.json to /home/site it works correctly.
PS
An analogous problem happens when the database is empty and we start any flow (which initializes the database). Task hub name should be resolved to whatever is present in the configuration, and it is not. I assume the default value (of "dbo") is used instead. After moving host.json one directory up, this issue is resolved as well.
Hi @Kobudzik , can you confirm that you're running
- InProc version of DfMon.
- In "injected" mode (as part of your Function App).
- With MSSQL Durability Provider.
Did I infer this correctly?
Hi @Kobudzik , can you confirm that you're running
- InProc version of DfMon.
- In "injected" mode (as part of your Function App).
- With MSSQL Durability Provider.
Did I infer this correctly?
- We are using "dotnet-isolated" runtime, so package for DFM is DurableFunctionsMonitor.DotNetIsolated. In the post, I linked durablefunctionsmonitor.dotnetbackend by mistake, we don't use it, but the implementation of TryGetHubNameFromHostJson method is the same for isolated DFM package.
- Yes, we are running in injected mode.
- Yes, we are using MSSQL.
Thanks for that info. And just to clarify one more thing:
as the last resort it gathers task hub names from the database, but in our case db was empty,
If you're saying the DB is empty - then DfMon is actually supposed to fail.
It shouldn't show data from non-existing Task Hubs, and more importantly, it should never create Task Hubs, if they don't exist yet.
So I'd say what you're observing is an expected behavior.
What would be your expectation in this case then?
What would be your expectation in this case then?
If there is a method that resolves hub name from three possible sources, I expect it to check three sources correctly, and as I mentioned looking for host.json outside project folder is surprising.
If you're saying the DB is empty - then DfMon is actually supposed to fail.
DfMon does not always fail when DB is empty. For the case with empty database it did fail and the exception was:
Exception: DurableFunctionsMonitor.DotNetIsolated.DfmUnauthorizedException: Task Hub 'ReportManager' is not allowed.
That is because it didn't resolve any task hub name, since DFM_HUB_NAME was empty, host.json was resolved incorrectly and DB was also empty. When I specify DFM_HUB_NAME, DfmUnauthorizedException does not happen anymore, as task hub is registered correctly then. With DFM_HUB_NAME and empty database I can run DFM/MyTaskHub and I see no exception, just empty list.
Also this is bad:
An analogous problem happens when the database is empty and we start any flow (which initializes the database). Task hub name should be resolved to whatever is present in the configuration (host.json: extensions.durableTask.hubName), and it is not. I assume the default value (of "dbo") is used instead. After moving host.json one directory up, this issue is resolved as well.
I know this isn't DFM problem, but it seems related. These issues happen both locally and at our environments using k8s.
Should be fixed in v6.4. Pls, validate.