Problem with allowing injection of TTenant directly is that this can block the thread if the Task that does the resolution hasn't completed already yet. It can block either for very minute amount of time (tenant grabbed from cache etc), or for potentially a longer time if the TTenant needs to be initialised (i.e its the first request to the tenant, so container / pipelines need to be built etc).
This means it has a side effect that isn't explicit to the consumer.
To improve this, I will support the injection of Task<TTenant> which then makes it explicit that there is work (potnentially) to be done when resolving a tenant. It's more than likely that in most applications the Task will already have been completed when injected, but there is always potential (as described above) that it may not be.
Now the consumer can decide whether it blocks (i.e Task.Result) or whether it awaits the task. I imagine it would always be more preferable to await.
Problem with allowing injection of
TTenantdirectly is that this can block the thread if the Task that does the resolution hasn't completed already yet. It can block either for very minute amount of time (tenant grabbed from cache etc), or for potentially a longer time if the TTenant needs to be initialised (i.e its the first request to the tenant, so container / pipelines need to be built etc).This means it has a side effect that isn't explicit to the consumer.
To improve this, I will support the injection of
Task<TTenant>which then makes it explicit that there is work (potnentially) to be done when resolving a tenant. It's more than likely that in most applications the Task will already have been completed when injected, but there is always potential (as described above) that it may not be.Now the consumer can decide whether it blocks (i.e Task.Result) or whether it
awaitsthe task. I imagine it would always be more preferable to await.