Andrea Cosentino created CAMEL-23142:
----------------------------------------

             Summary: 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
             Fix For: 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)

Reply via email to