When the QueueWorker attempts to create a contact that already exists, the process fails and the item remains in the queue. While this is standard retry behavior, it's causing unnecessary backlog for duplicate subscriptions. Should we implement more granular error handling—perhaps catching UniqueConstraint errors to 'fail silently' or update the record, while only retrying for transient issues like timeouts?

Issue fork brevo-3574001

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

kensae created an issue. See original summary.

kensae opened merge request !13

kensae’s picture

kensae commented

In my MR if the error in the queue is of the type ApiExcepion and the code in the responsebody is 'duplicate_parameter', I try to update the contact.

kensae’s picture

kensae commented
Status: Active » Needs review
renrhaf’s picture

renrhaf
Primary language French
Location 📍 Strasbourg 🐦🦜
commented
Status: Needs review » Needs work
kensae’s picture

kensae commented

I agree that passing updateEnabled explicitly would be a better approach.
Handling all contact creation functionality in the centralized ContactsApiClientHelper, would allow to set a default for the entire module.
https://www.drupal.org/project/brevo/issues/3588474

renrhaf closed merge request !13

renrhaf’s picture

renrhaf
Primary language French
Location 📍 Strasbourg 🐦🦜
commented
Status: Needs work » Closed (duplicate)

The QueueWorker duplicate-contact handling is resolved by #3588474 (MR !18, now merged into 1.0.x): ContactsApiClientHelper::createContact() now defaults updateEnabled to TRUE, so an existing contact is upserted instead of throwing duplicate_parameter, and the queue worker calls it with bubbleExceptions = TRUE so genuine transient failures still bubble up and let the item retry.

This matches the approach we agreed on in #6 (explicit updateEnabled, centralised in ContactsApiClientHelper). Closing as a duplicate of #3588474.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.