You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2026/03/06 19:49:00 UTC

[jira] [Updated] (CAMEL-23142) camel-google-pubsub: Add maxDeliveryAttempts enforcement to prevent infinite redelivery loops

     [ https://issues.apache.org/jira/browse/CAMEL-23142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-23142:
--------------------------------
    Fix Version/s: 4.18.1

> camel-google-pubsub: Add maxDeliveryAttempts enforcement to prevent infinite redelivery loops 
> ----------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-23142
>                 URL: https://issues.apache.org/jira/browse/CAMEL-23142
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-google-pubsub
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>             Fix For: 4.18.1, 4.19.0
>
>
> When a Google Pub/Sub subscription is configured with a dead-letter policy and short retry delays (e.g., {{--min-retry-delay=5s}}, {{--max-retry-delay=15s}}), the camel-google-pubsub consumer enters an infinite redelivery loop. The component exposes the per-message delivery attempt count via the {{CamelGooglePubsubDeliveryAttempt}} header, but has no mechanism to compare it against the subscription's {{maxDeliveryAttempts}} threshold and short-circuit processing.
> The consumer keeps processing the same failing message in a tight loop until Pub/Sub's server-side enforcement eventually routes it to the DLQ. With short retry windows, this causes unnecessary load and resource consumption.
> Increasing {{--min-retry-delay}} to 30s+ alleviates the symptom but does not address the root cause.
> h3. Example subscription configuration that triggers the issue
>   {code}
>   gcloud pubsub subscriptions create publisher-subscription
>     --topic=publisher-topic
>     --ack-deadline=10
>     --dead-letter-topic=publisher-topic-dlq
>     --max-delivery-attempts=5
>     --min-retry-delay=5s
>     --max-retry-delay=15s
>   {code}
> Implementation:
> Add a {{maxDeliveryAttempts}} endpoint parameter to the consumer. When the delivery attempt count of an incoming message reaches the configured maximum, the consumer automatically nacks the message without processing it, allowing Pub/Sub to route it to the dead-letter topic.
> The value is resolved as follows:
> If explicitly set via the endpoint URI (e.g., {{?maxDeliveryAttempts=5}}), that value is used.
> If not explicitly set, the component auto-fetches the value from the subscription's dead-letter policy at consumer startup using {{SubscriptionAdminClient}}.
> If auto-fetch fails (insufficient permissions, no dead-letter policy, emulator limitations), enforcement is disabled and a warning is logged.
> A value of {{0}} disables enforcement (default, preserving backward compatibility).
> Enforcement applies to both asynchronous and synchronous pull modes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)