Azure-functions-host: Service bus trigger only fires when browser open viewing the function in portal

[damienpontifex]

Please provide a succinct description of the issue.

Repro steps

Provide the steps required to reproduce the problem

1. Azure function that is triggered from Service Bus Topic hosted on a Consumption AppService Plan
2. Monitor the output of jobs in normal usage -> Noticed none is processed
3. Open up function and view in Azure Portal -> Items are processed as normal

Expected behavior

Function should be triggered always

Actual behavior

Function only triggered when viewing the logs in the azure portal

Known workarounds

None so far

Related information

Provide any related information

• C#

[damienpontifex]

More information...after viewing the function in the portal, then closing the portal blade, it continues to fire for a period and then stops. Maybe some sort of idle timeout is occurring...

[fabiocav]

Could you share your function app name (or follow the steps here to share information that would allow us to find it)?

Is this on the consumption or App Service plan? If the latter, please make sure "Always On" is enabled as it is a requirement for these scenarios.

[damienpontifex]

UTC execution time: 2017-06-22T03:51:02.236
execution Id value: Id=1563c9b0-8f0c-4462-9c30-77bfcfc98f10, Duration=2332ms)
Location: Australia East

And the App Service has pricing tier = Consumption.

[apedzko]

Hi!

We have faced exactly the same issue with servicebus trigger on consumption service plan.
It makes impossible for us to rely on the main use case of the function app: reactively react on the external event.

Could you please reply whether there is a timeline to resolve this issue?

[fabiocav]

@damienpontifex looks like the scale controller is attempting to wake your site app, but the connection string you've provided doesn't have manage rights, which is a requirement. Can you use a connection string with manage permissions and see if that resolves the issue?

@apedzko not sure if your issue is similar, so it's hard to say what would resolve it or when. If you can open an issue providing the same information Damien shared, that would help us investigate.

[apedzko]

My function will only be getting messages from the queue, thus i am using the shared access policy with only "Listen" priviliges. Are you saying that i should grant the "Manage" priviliges to the function? Why does it need "Manage" permissions to use from the queue? From the first glance it looks like a security breach.

[damienpontifex]

I'll update with a manage connection string and check.

@fabiocav I assume this is a bug to not allow least privilege connection strings?
The portal has a drop down on the 'Integrate' tab to select 'Access Rights' = 'Listen' so I assume it was planned to allow this.

Also saw your comments in Azure/azure-webjobs-sdk#1177 that this manage behaviour will be dropped with .net core support due to SB Library.

[fabiocav]

Currently, this behavior is by design and unfortunately a requirement in order to have the scale controller properly inspect SB to decide whether there's work to be handled.

We have worked with the SB team to find a reliable way to accomplish this without requiring manage rights and @tohling may have more information on that and what the plans to improve this are.

My comment about the manage operations support was within the scope of the WebJobs SDK (and the Functions Runtime), the scale controller/infrastructure would still have that requirement for the time being.

[fabiocav]

@apedzko please see the comment above. Currently, manage rights are indeed required when using the consumption plan.

[damienpontifex]

@fabiocav (out of interest) why does this work when viewing the function app in the browser? Does it have something to do with the portal waking up the function app vs the scale controller waking it up?

We had got to the point of just leaving a browser tab open to make it work 😜

[fabiocav]

That's exactly what is happening :)

The portal talks to the runtime, so it wakes it up. The scale controller is there do do that (and handle scaling as load increases/decreases), but in this case, it can't get the information it needs to start the runtime.

[tohling]

@damienpontifex, @apedzko to mitigate, kindly switch to managed rights for now. This issue was fixed earlier but there is a regression due to a recent code change. We are actively fixing this and I have reopened the issue here: https://github.com/Azure/azure-webjobs-sdk-script/issues/1048.

[fabiocav]

Thanks @tohling!

@damienpontifex, @apedzko I'm closing this issue and we'll keep #1048 updated as we work on the fix. Thanks for your patience with this!