7.1.2: HubSpot fetchleads windowing and contact dedupe hotfix tracking

Summary

This is a sanitized tracking/bug report for hotfixes that were needed after upgrading to Mautic 7.1.2. No environment-specific details are included here. The goal is to make the behavior easy to re-check before future Mautic upgrades and to confirm whether upstream changes make the hotfixes unnecessary.

Observed issues

1. HubSpot fetchleads can behave like an unbounded historical sync

   Command shape:

   bash复制

   php bin/console mautic:integration:fetchleads \
     --integration=Hubspot \
     --time-interval='10 minutes' \
     --limit=50 \
     --env=prod \
     --no-interaction

   Expected behavior:

   • --time-interval should constrain the HubSpot contact pull to the requested recent modification window.
   • --limit should keep the run bounded enough for recurring cron use.
   • The command should not recurse through a large historical contact set when a short interval is supplied.

   Observed behavior:

   • The HubSpot integration path appeared to ignore the intended modification window in the contact API query.
   • Pagination could continue through a much larger result set than expected for a short recurring cron window.
   • The local hotfix was to query contacts by HubSpot lastmodifieddate, pass explicit start/end bounds, remove internal Mautic command parameters from the outbound API query, use iterative pagination, and cap page size from --limit.

2. Contact dedupe can fail while merging contacts with an existing Stage

   Command shape:

   bash复制

   php bin/console mautic:contacts:deduplicate:ids --contact-ids=<ids> --env=prod --no-interaction

   Failure shape:

   复制

   ORMInvalidArgumentException: A managed+dirty entity Proxies\__CG__\Mautic\StageBundle\Entity\Stage with ID #... can not be scheduled for insertion.

   Expected behavior:

   • Deduplicating/merging contacts that reference an existing Stage should not try to schedule that Stage for insertion.

   Observed behavior:

   • The merge failed until the Lead.stage association was adjusted locally.
   • The local hotfix was to remove cascadePersist from the Lead.stage relationship while keeping merge/detach behavior.

3. Full dedupe orchestration should not depend on a non-executable console file

   Command shape:

   bash复制

   php bin/console mautic:contacts:deduplicate --batch=100 --processes=1 --env=prod --no-interaction

   Observed behavior in a Docker-based runtime:

   复制

   sh: 1: exec: /var/www/html/bin/console: Permission denied

   Local mitigation was to ensure /var/www/html/bin/console is executable in the image. A more robust upstream behavior may be to spawn the console through the current PHP binary or ensure executable permissions are consistently present in supported Docker images.

Local upgrade verification checklist

Before removing these hotfixes during a future upgrade, verify:

• HubSpot fetchleads with a short --time-interval performs a bounded modified-contact pull and does not page through full history.
• Contact dedupe by explicit IDs succeeds when contacts reference an existing Stage.
• Full mautic:contacts:deduplicate can spawn worker commands successfully in the supported Docker image/runtime.
• No duplicate contacts are introduced by the recurring HubSpot cron after a bounded test run.

If these behaviors are already fixed in a newer branch, this issue can serve as the checklist for removing local compatibility patches.

---

Care about this issue? Want to get it resolved sooner? If you are a member of Mautic, you can add some funds to the Bounties Project so that the person who completes this task can claim those funds once it is merged by a member of the core team! Read the docs here.