Open ProTip opened 2 months ago
This is because the cosmos input binding throws if the item is not found. Relevant code here: https://github.com/Azure/azure-functions-dotnet-worker/blob/efd0aefe0a6564759f4aac57be8d6a7b8293ca86/extensions/Worker.Extensions.CosmosDB/src/CosmosDBConverter.cs#L114-L115
This is by design. If you want more control, you may consider binding to a CosmosClient
instance which allow you to query and manage your data in any way you prefer. Please refer the samples here.
@kshyju I would like to challenge that this overall behavior is by design. I'm aware the binding throws, but are you suggesting the function returning a 500, internal server error, is by design instead of an oversight?
If so this isn't mentioned in the migration documentation; it used to simply place null
in the property.
The behavior is also not mentioned in the binding documentation.
I agree, whether this was by design or not, whether the previous functionality was a mistake or not, it has changed and needs documenting on migration guides, as it's a breaking change.
Why not continue with the existing functionality so that the binding doesn't become useless for so many of us?
Also, we have had an open ticket about this for months with no feedback (see Protip's reference), can we please keep this conversation going since we are staring down the deadline for migration?
Description
I'm upgrading previously unmaintained application to the isolated hosting model. Unfortunately the
CosmosDBInput
binding is not behaving as expected. The following information has been pulled from the stack trace when attempting to access a missing resource.The CosmosClient is receiving a 404 from the emulator:
However an exception is thrown trying to convert that response to the property type:
Steps to reproduce
Try using
CosmosDBInput
to access a missing resource with the isolated worker model.