[
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)
