CosmosDBInput returning 500 instead of 404 when item does not exist

[ProTip]

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:

Error:Microsoft.Azure.Cosmos.CosmosException : Response status code does not indicate success: NotFound (404)

However an exception is thrown trying to convert that response to the property type:

Error converting 1 input parameters for Function 'GetPreflightById': Cannot convert input parameter 'document' to type 'PreflightService.Models.PreflightRecord' from type 'Microsoft.Azure.Functions.Worker.Grpc.Messages.GrpcModelBindingData'

Steps to reproduce

Try using CosmosDBInput to access a missing resource with the isolated worker model.

[kshyju]

This is because the cosmos input binding throws if the item is not found. Relevant code here:

azure-functions-dotnet-worker/extensions/Worker.Extensions.CosmosDB/src/CosmosDBConverter.cs

Lines 114 to 115 in efd0aef

	ResponseMessage item = await container.ReadItemStreamAsync(cosmosAttribute.Id, new PartitionKey(cosmosAttribute.PartitionKey));
	item.EnsureSuccessStatusCode();

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.

[ProTip]

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

[bronthulke]

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?