Using FunctionContext.RetryContext throws Nullreference on ServiceBusTrigger

Question

I try to receive the number of retries in a ServiceBusTrigger: (from a servicebusqueue)

using Microsoft.Azure.Functions.Worker;

[Function("SyncQueue")]
public async Task HandleSyncEvent([ServiceBusTrigger("sync-events", Connection = "ServiceBus-ConnectionString")] string syncEvent, FunctionContext context)
{
   var retryCount = context.RetryContext?.RetryCount ?? 0;
   if (retryCount > 0) {}
}

But while the RetryContext is not null the underlying Properties (RetryCount, MaxRetryCount) throw a NullreferenceException when I try to access them.

Can I solve this without wrapping a try..catch around the property when there are no retries?

Stacktrace:

System.NullReferenceException
  HResult=0x80004003
  Message=Object reference not set to an instance of an object.
  Source=Microsoft.Azure.Functions.Worker.Grpc
  StackTrace:
   at Microsoft.Azure.Functions.Worker.Grpc.GrpcRetryContext.get_RetryCount()
   at cse.Functions.HandleSyncQueue.<HandleSyncEvent>d__2.MoveNext() in C:\git\backend\services\src\Synchronization\cse.Functions\HandleSyncQueue.cs:line 26

Does this answer your question? [What is a NullReferenceException, and how do I fix it?](https://stackoverflow.com/questions/4660142/what-is-a-nullreferenceexception-and-how-do-i-fix-it) — knittl, Sep 20 '22 at 13:08
@knittl no. I am aware about NullReferences :) As I wrote the Exception occurs in a property that is not in my control but from the Framework — Ole Albers, Sep 20 '22 at 13:12
@OleAlbers but you are already using null-safe navigation (`?.`) so there must not be an NRE. — knittl, Sep 20 '22 at 13:19
This looks like a bug in the Azure library you're using. Are you using `Microsoft.Azure.Functions.Worker.Grpc` version **1.4.1**? — Dai, Sep 20 '22 at 13:24
Yes. But from Experience I expect more of a configuration issue than a bug — Ole Albers, Sep 20 '22 at 13:31
@OleAlbers I know that feeling, but when a `NullReferenceException` is thrown _inside_ third-party code, _it's not your fault_. I took a peek at some of the code in `Microsoft.Azure.Functions.Worker.Grpc` on GitHub and I saw a complete lack of ctor parameter validation, not even null checks, so I'm almost certain this is the fault of that library's authors. — Dai, Sep 20 '22 at 13:37
@OleAlbers: What is the implementation of `RetryCount { get { …; } }`? It looks like the NPE is happening inside the getter, not in your code. — knittl, Sep 20 '22 at 13:45

Ole Albers · Accepted Answer · 2022-09-20T14:16:58.657

0

I solved this by using DeliveryCount instead

Following the Docs this value should contain the exactly same value as context.RetryContext.RetryCount-1

so changing the Header to

[Function("SyncQueue")]
public async Task HandleSyncEvent([ServiceBusTrigger("sync-events", Connection = "ServiceBus-ConnectionString")] string syncEvent, int deliveryCount, FunctionContext context)
{
    if (deliveryCount > 1) {}
}

had the desired effect

edited Sep 20 '22 at 14:16

answered Sep 20 '22 at 14:09

Ole Albers

8,715
10
73
166

1

The `DeliveryCount` is a property from the Service Bus message, not Functions SDK. I _suspect_ that SB trigger does not support retries (see https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-error-pages), and you're using the Isolated Worker SDK, that's why you get an exception. I suggest you follow up on the Functions SDK repo to see why `RetryContext.RetryCount` throws NRE as it was supposed to be addressed already according to https://github.com/Azure/azure-functions-dotnet-worker/issues/316 – Sean Feldman Sep 20 '22 at 16:15

Using FunctionContext.RetryContext throws Nullreference on ServiceBusTrigger

1 Answers1