Azure Function v2 在处理 StorageException 后始终返回内部服务器错误 500

Question

Imagine you have an Azure Function (v2) that uses Table storage, you run but the entity with SomePartitionKey/SomeRowKey exists (eg you run the below twice):

[FunctionName("SomeEntity")]
public static async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "someentity")] HttpRequest req,
                                            [Table("SomeEntities")] IAsyncCollector<SomeEntity> collector,
                                            ILogger logger)
{

    try
    {
        SomeEntity se = new SomeEntity()
        {
                PartitionKey = "SomePartitionKey",
                RowKey = "SomeRowKey"
        };
        await collector.AddAsync(se);
        await collector.FlushAsync();

        return new OkResult();
    }
    catch (Microsoft.WindowsAzure.Storage.StorageException e)
    {
        logger.LogError("There was an error processing the request.", e);
        return new StatusCodeResult(409);
    }
}

When this runs and the Entity already exists, as expected, it throws a StorageException. My issue is that even though I catch the exception and attempt to return a StatusCodeResult(409) the actual response sent to the client is always an Internal Server Error (500).

My questions are:
a) Is this the result of cleanup logic of the Function attempting to call FlushAsync() again on the collector resulting in an unhandled StorageException which causes an Internal Server Error (500). b) If yes to a), is it possible to prevent this?
c) Aside from checking if the entity exists first is there any best practice for this scenario?

Answer 1

One of the great things about Azure Functions NuGet packages is that they enable source linking. Ensure you have Enable Source Link support checked in your Visual Studio options, and you'll be able to see exactly what their code is doing. Once your function app is running, you can choose to break when any CLR Exceptions are thrown.

If you do this, you'll see that the exception is thrown as expected from FlushAsync , your code is catching it, and returning the 409 result. Then, after your function returns, the same exception is thrown again (because FlushAsync is called again, outside your function), it's caught and a wrapper exception is thrown with the message Error while handling parameter collector after function returned , which in turn is caught and a wrapper exception is thrown with the message Exception while executing function: SomeEntity , which in turn is caught and just a plain old 500 error is returned to the client.

So:

a) Is this the result of cleanup logic of the Function attempting to call FlushAsync() again on the collector resulting in an unhandled StorageException which causes an Internal Server Error (500).

Yes. If you enable Source Link support and Break when Thrown, then you can debug right through the Azure Functions runtime and see this happen.

b) If yes to a), is it possible to prevent this?

c) Aside from checking if the entity exists first is there any best practice for this scenario?

I would not recommend check-then-insert. You'll end up with race conditions.

From the docs :

This output binding does not support updating existing entities. Use the TableOperation.Replace operation from the Azure Storage SDK to update an existing entity.

As a general rule, the Azure Functions binding for any given service is for the simple use case. In the case of Azure Storage Tables, the simple use case is only inserting entities.

However, you can always just use the Storage SDK yourself. That's pretty much just what the binding is doing for you anyway. This binding does some batching, too, but that's not too hard to implement if you need it.

You can also do a "halfway": have the Tables binding bind to a CloudTable instead of an IAsyncCollector<SomeEntity> . That way you'll automatically use the appropriate connection string; you'll just need to write your own TableOperation.InsertOrReplace code.