Skip deferred binding for CosmosDB trigger #9027
Conversation
liliankasem
force-pushed
the
liliankasem/sdk-binding/optoutcosmostrigger
branch
from
e7b0020 to
a6e4d8e
Compare
| bool containsExpression = BindingAttributeContainsExpression(bindings); | ||
|
|
||
| // If the trigger is a CosmosDBTrigger, we do not want to use ParameterBindingData as it is not supported | ||
| bool isCosmosTrigger = IsCosmosDBTrigger(triggerMetadata); |
There was a problem hiding this comment.
It doesn't feel right to me to insert single extension specific logic into this core layer. Can this be pulled into a formal extensibility behavior? Can we delegate the supported decision to the BindingMetadata itself, and extenders can control it?
There was a problem hiding this comment.
Yup agree, was trying to have a quick patch in place for if we release Cosmos soon.
However, I did sync with Fabio about this today and since Cosmos is not in any rush to be released we can focus on refactoring the supportsDeferredBinding attribute for extensions and the function metadata generator on the worker to have more granular information about what bindings support deferred binding rather than the blanket "all or nothing" approach we have in place today.
As a result, I'll abandon this PR and create an issue for the refactor work that needs to happen in the worker
Issue describing the changes in this PR
resolves #9026
With the way the cosmos db sdk is implemented it is not possible to use ParameterBindingData/DeferredBinding for cosmos DB triggers with out-of-proc workers. We need to make sure we continue to handle triggers the same way we do today, hence the skipDeferredBinding flag.
See this issue discussion for reference.
Pull request checklist
release_notes.md