ListInputBindings not invoked on grpc interface since 1.12 update

[dandoj]

• [ ] bug report -> please search issues before submitting
• [ ] documentation issue or request
• [ x] regression (a behavior that used to work and stopped in a new release)

Issue description

Since the upgrade to Dapr 1.12 in container apps (which looks like it was towards end of last week), we are seeing an issue whereby the when using the grpc interface with Dapr the ListInputBindings method is not being invoked. This has the the behaviour of any service bus queue binding is subscribed to

Steps to reproduce

1. create application that uses gprc with dapr
2. create a service bus binding with 'input' direction
3. implement a class that implemetns AppCallback.AppCallbackBase
4. override the ListInputBindings method

Expected behavior The ListInputBindings method is invoked on startup, and only bindings defined there are subscribed to. Messages sent to the queue are not invoked

Actual behavior All 'input' bindings are subscribed to whether or not they are defined in the ListInputBindings, and then the binding is invoked when it shouldn't

Screenshots from appinsights - this method is no longer called

implementation of method

public override Task<ListInputBindingsResponse> ListInputBindings(Empty request, ServerCallContext context)
    {
        var result = new ListInputBindingsResponse();
        result.Bindings.Add(PortfolioRequestsBinding);

        return Task.FromResult(result);
    }

log line saying app has loaded the input binding

time="2024-05-16T16:44:38.176779761Z" level=info msg="successful init for input binding (sbq-api-audit-events (bindings.azure.servicebusqueues/v1))" app_id=grady-gateway instance=ca-grady-gateway-uat1--8a3vdsy-56fcdf4b7d-tljxx scope=dapr.runtime.processor.binding type=log ver=1.12.5

binding definition

[matthiasng]

We are currently facing the same problem. At the beginning we didn't had any direction set on our bindings and everything worked till the 1.12.5 update (on our container apps envs this was around the 09 of May). From then on input bindings stopped working complete and messages just stuck in the queues forever.

After setting the direction to input,output we see the same behaviour described in this issue. Messages get processed again but by random container apps that are not even subscribed to the binding.

We also tried to add a scope to the components without luck (same behaviour) as before.

[dandoj]

We had the same issue with the “optional” bindings. We had to patch production to put direction on all components. Then we found the behaviour I originally posted yesterday. We’ve now implemented a workaround to have separate input and output bindings. We also had to delete the container apps and redeploy as they appeared to be caching the old bindings.

[m-moris]

I faced a similar problem with "cron binding". The problem started right after the container app Dapr was updated to 1.12.5.

I have issued the following Issue regarding this problem.

https://github.com/dapr/dapr/issues/7828