### Problem/Motivation The module reacts to order and user activity through several entry points, and each of them resolves the Mautic contact by email address and creates one when no match is found: - `CartUpdateSubscriber`, on `CART_ENTITY_ADD`, `CART_ORDER_ITEM_UPDATE`, `CART_ORDER_ITEM_REMOVE`, `ORDER_UPDATE` and `commerce_order.place.post_transition` - `CustomerDetailsSubscriber`, on `commerce_order.place.post_transition` and `commerce_order.paid.post_transition` - `OrderTransitionSubscriber`, on `place`, `validate` and `fulfill`, which queues a customer metrics recalculation - `CustomerMetricsSyncQueueWorker` and `AbandonedCartSyncQueueWorker`, when those queues run That is the right behavior for ordinary shop traffic, where an order save really does represent something a customer did. It is the wrong behavior for any operation that rewrites customer data deliberately: a data subject request, a migration, a bulk import, a repair script. There, an entity save is a side effect of the operation rather than a customer action, and the sync turns it into a Mautic write nobody asked for. There is currently no way for a consumer to say "this save is mine, stand down". #### A concrete case We hit this building a GDPR tool that changes or erases a customer's data across the store and Mautic. The tool writes the store first and Mautic second, deliberately: the customer metrics this module maintains are computed from orders, so if the store is not correct first, a later recalculation finds no orders for the new address and writes zeros onto the contact. For an **address change**, if the customer has a draft order, saving it fires `CartUpdateSubscriber::onOrderUpdate()`. The order is in `draft` and its email changed, so the subscriber resolves the contact by the new address, finds nothing, and creates one. The tool then updates the original contact by id. Mautic ends with two contacts: the original carrying the old address and the whole purchase history, and a new one carrying the new address and nothing. For an **erasure** it is worse. The anonymized address is written to the order, the subscriber creates a contact holding that anonymized address, and the tool then deletes the original contact by id. The erasure ends by adding a contact to Mautic. On the site where we found this, 172 customers currently have a draft order, so this is not a corner case. There is a second effect that matters even when no contact is created: the subscribers issue a synchronous HTTP call to Mautic from inside whatever database transaction the calling operation opened. ### Proposed resolution Add a suspension service that a consumer holds for the duration of an operation, and that every entry point consults before doing any work. ```php $suspender = \Drupal::service('commerce_mautic_connect.sync_suspender'); $suspender->suspend(); try { // The operation: entity saves, queue items, whatever it needs. } finally { $suspender->resume(); } ``` Points to guard, so that a suspended operation is genuinely quiet rather than partially quiet: - the three event subscribers listed above, at the top of each listener - `CustomerMetricsSyncQueueWorker::processItem()` and `AbandonedCartSyncQueueWorker::processItem()`, so that an item queued before the suspension does not fire during it A few design points worth settling in review: - **Suspension is per request, not persisted.** It is a property of the operation in progress, not a site setting. A suspension that outlives a fatal error would silently disable the module. - **Nesting should be counted rather than boolean**, so that two nested operations do not resume each other's sync early. - **Queued items are the open question.** Suspending the subscriber that *creates* the queue item is straightforward. An item already in the queue, created before the operation started, is not: skipping it silently loses a legitimate sync. Re-queueing it, or letting the worker run and accepting it, may both be defensible. Worth deciding explicitly rather than by omission. This is additive and changes no default behavior: a site that never calls `suspend()` behaves exactly as it does today. ### Remaining tasks - Agree the service shape and the queue-worker behavior - Implement and add a kernel test that saves an order and a user under suspension and asserts no Mautic call is made - Document it in the README, since the value of the feature is entirely in consumers knowing it exists ### User interface changes None. ### API changes New service, `commerce_mautic_connect.sync_suspender`. No existing signature changes. ### Related `advanced_mautic_integration`'s `UserSynchronizer::push()` has the same shape: it resolves by email before checking whether it has anything to write. That is a separate project and out of scope here, but a consumer suspending this module's sync may reasonably expect that one to be quiet too.