Support passing binding data when invoking via admin endpoint

[paulbatum]

This stack overflow post highlights a scenario where using the admin endpoint for testing is awkward because the function was written to accept additional binding parameters such as "deliveryCount" and there is no way to pass that when invoking the function via HTTP.

https://stackoverflow.com/questions/50725773/servicebustrigger-with-enqueuetimeutc-argument-fails-when-triggered-via-http-end

Here's the example function:

[FunctionName("ServiceBusQueueTriggerCSharp")]                    
public static void Run(
    [ServiceBusTrigger("myqueue", AccessRights.Manage, Connection = "ServiceBusConnection")] 
    string myQueueItem,
    Int32 deliveryCount,       // this fails
    DateTime enqueuedTimeUtc,  // this fails too
    string messageId,
    TraceWriter log)
{
    log.Info($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
    log.Info($"EnqueuedTimeUtc={enqueuedTimeUtc}");
    log.Info($"DeliveryCount={deliveryCount}");
    log.Info($"MessageId={messageId}");
}

This issue tracks adding the ability to specify the additional binding data via query parameters as this seems like the most natural way to pass in additional data.

[maryammadzadeh]

We are observing the same behavior with ServiceBusTriggers and messages. Should we open a separate Issue for this? We want to read the properties each time the function runs regardless of who invokes that call.

[paulbatum]

No need to open a separate issue. This issue tracks exactly the problem you're encountering. The best workaround I can recommend right now is that you make a separate function (such as a HTTP triggered function) that writes a message to the appropriate service bus queue and you trigger that new function in order to test your service bus triggered function.

[paulbatum]

Oh. Perhaps I misunderstood you then. This entire issue is about awkwardness with testing a service bus triggered function using the "test" functionality in the azure portal that uses the admin endpoint.

If your issues do not relate to the admin endpoint and scenarios where you are manually triggering the function, then it is not related to this issue and you should file something separate.

[maryammadzadeh]

We would like to be able to read a message's enqueued time and other meta details for monitoring purposes. We are unable to read the messageId property, or the other ones. We see the same error posted in the original stack overflow post mentioned in the issue. Will this be fixed before GA? And thanks for your replies!

[paulbatum]

The original stack overflow post is also specifically about calling a service bus triggered function manually, via HTTP. Please, file a new issue (link it here) with details about your scenario. If you have simple repro steps that can be followed, that would be ideal.

[evilpilaf]

I guess this is abandoned? Is there any information on this issue?

Like @paulbatum mentions in his original post, it's not possible to test non-http functions which are taking additional binding information via the admin endpoint. having to create a ServiceBus and an enqueuer to be able to test a consumer of queue messages is too much

[paulbatum]

I think the current information on this issue is up to date. It would be useful improvement, but hasn't been sufficiently high priority to be implemented.

[jianawu]

Hi @paulbatum ,
Is there any plan about this issue till now? Really look forward to using this feature :)

[paulbatum]

I think the current information on this issue is up to date as of 2021. It would be useful improvement, but hasn't been sufficiently high priority to be implemented.

[smokedlinq]

Just came across this and it's a problem as ServiceBusTrigger sets the deliveryCount to 1 on the first attempt but the admin endpoint defaults it to 0.