Dapr - EventHub component - Excessive duration after inactivity

[foliv57]

This issue is a:

• bug report
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Issue description

We are using "pubsub.azure.eventhubs" component to publish events to an Azure EventHub from an ASP.NET web application.

After cold start of the containers, the duration of the first publish event is acceptable (1s to 3s). But after a period of inactivity (between 1 and 2 hours), the first publish event takes 15s.

Below the Dapr container log that we see after inactivity:

time="2026-04-29T06:07:46.720941374Z" level=info msg="gRPC API Called" app_id=`XXXXXX-dapr code=0 duration=14801 instance=XXXXXXX--r1-2-1-alpha-0-115-7c457b6544-z9qbp method=/dapr.proto.runtime.v1.Dapr/PublishEvent scope=dapr.runtime.grpc.api-info type=log useragent="grpc-dotnet/2.76.0 (.NET 10.0.7; CLR 10.0.7; net10.0; linux; x64) dapr-sdk-dotnet/v1.17.4+896bff16f9e29feb7a9bd9749a38640103d3b352" ver=1.16.4-msft.2

What we already tried:

• Replace managed identity by connection string to prevent token aquisition latency
• Setup min replica to 1 to keep always 1 container app replica
• Ensured that the DaprClient is injected as Singleton

Environement

• Dapr component type: pubsub.azure.eventhubs
• Client SDK: Dotnet Dapr.Client 1.17.0
• App framework: .NET 10
• Hosting: Azure Container App
• Dapr version: 1.16.4-msft.2

Steps to reproduce

• Deploy an Azure Container App that uses a "pubsub.azure.eventhubs" component to publish events to an Azure EventHub.
• Make a first cold start publish (Should be fast)
• Wait for 1 or 2 hours with no activity
• Make a second publish (Should take more than 10s)

Expected behavior
First publish after inactivity should not take longer than after cold start and be reasonable (~1s to 3s)

Actual behavior
First publish after inactivity takes more than 15s.

[foliv57]

We activated full Dapr debug logs and have this log sequence when the problem happen:

[Apr 29 11:02:52.471263] azeh.Conn: Error closing old client: *Error{Condition: amqp:connection:forced, Description: The connection was closed by container 'XXXXXX_G26' because it did not have any active links in the past 60000 milliseconds. TrackingId:XXXXXX_G26, SystemTracker:gateway5, Timestamp:2026-04-29T10:58:47, Info: map[]}
[Apr 29 11:02:52.471267] azeh.Conn: Creating a new client (rev:20)
[Apr 29 11:02:52.471270] azeh.Conn: Creating new client, current rev: 20
[Apr 29 11:02:52.636586] azeh.Conn: Client created, new rev: 21, took 165ms
[Apr 29 11:02:58.813708] azeh.Producer: [c:1,l:-Ffci,p:] Sending message with ID 80d5496f-3c7e-4812-551c-dda5fc0924c2 to partition ""
[Apr 29 11:02:58.813748] azeh.Conn: (c:1,l:-Ffci,p:, SendEventDataBatch) Link was previously detached. Attempting quick reconnect to recover from error: *Error{Condition: amqp:link:detach-forced, Description: Idle link tracker, link -FfciuABLRMBC5vGKp-ofSDsAzgtXc5sCRF6-TtKksFIA8pZolegqw has been idle for 1800000ms TrackingId:XXXXX_G12, SystemTracker:XXXXX:EventHub:XXXXX, Timestamp:2026-04-29T09:18:13, Info: map[]}
[Apr 29 11:02:58.813752] azeh.Producer: (c:1,l:-Ffci,p:) Resetting retry attempts
[Apr 29 11:02:58.813766] azeh.Producer: (c:1,l:-Ffci,p:) Retry attempt -1 returned retryable error: *Error{Condition: amqp:link:detach-forced, Description: Idle link tracker, link -FfciuABLRMBC5vGKp-ofSDsAzgtXc5sCRF6-TtKksFIA8pZolegqw has been idle for 1800000ms TrackingId:XXXX_G12, SystemTracker:XXXX:EventHub:XXXX, Timestamp:2026-04-29T09:18:13, Info: map[]}
[Apr 29 11:02:58.813867] azeh.Conn: (c:1,l:-Ffci,p:) Error when cleaning up old link for link recovery: *Error{Condition: amqp:link:detach-forced, Description: Idle link tracker, link -FfciuABLRMBC5vGKp-ofSDsAzgtXc5sCRF6-TtKksFIA8pZolegqw has been idle for 1800000ms TrackingId:XXXX_G12, SystemTracker:XXXX:EventHub:XXXX, Timestamp:2026-04-29T09:18:13, Info: map[]}
[Apr 29 11:02:58.813878] azeh.Producer: (c:1,l:-Ffci,p:) Retry attempt 0 returned retryable error: *Error{Condition: amqp:link:detach-forced, Description: Idle link tracker, link -FfciuABLRMBC5vGKp-ofSDsAzgtXc5sCRF6-TtKksFIA8pZolegqw has been idle for 1800000ms TrackingId:XXXX_G12, SystemTracker:XXXX:EventHub:XXXX, Timestamp:2026-04-29T09:18:13, Info: map[]}
[Apr 29 11:02:58.813884] azeh.Producer: (c:1,l:-Ffci,p:) Retry attempt 1 sleeping for 4.704468513s
[Apr 29 11:03:03.519078] azeh.Conn: Creating link for partition ID ''
[Apr 29 11:03:03.549882] azeh.Conn: (c:21,l:N6Hyt,p:): Succesfully created link for partition ID ''
[Apr 29 11:03:03.549903] azeh.Producer: [c:21,l:N6Hyt,p:] Sending message with ID 80d5496f-3c7e-4812-551c-dda5fc0924c2 to partition ""
time="2026-04-29T11:03:03.677160628Z" level=info msg="gRPC API Called" app_id=XXXX-dapr code=0 duration=4863 instance=XXXX--0000014-d9bc879c9-zsn5r method=/dapr.proto.runtime.v1.Dapr/PublishEvent scope=dapr.runtime.grpc.api-info type=log useragent="grpc-dotnet/2.76.0 (.NET 10.0.7; CLR 10.0.7; net10.0; linux; x64) dapr-sdk-dotnet/v1.17.0+96c9b19cd1854bd2e69787d621c06fed1f8b0f17" ver=1.16.4-msft.2

Hope that it can help investigation.

[simonjj]

The debug logs point to the root cause: EventHub's AMQP idle link tracker is closing the link after 30 minutes of inactivity (1800000ms), and the connection after 60 seconds with no active links. On the next publish, Dapr has to re-establish the connection and link with retry backoff (~4.7s sleep), which accounts for the ~15s latency spike.

This is a Dapr sidecar behavior — the EventHub component should handle idle AMQP timeouts more gracefully (e.g., keep-alive pings or faster link recovery).

Routing to the Dapr team for investigation.