Campaigns Stuck in Queue with Postmark Integration

[alexanderbuergin]

Bug Report

We’ve encountered an issue with the Campaign plugin in combination with Postmark. Specifically, certain campaigns get stuck in the sending queue after reaching a specific number of sent emails. For example, if 1,000 out of 1,200 emails are sent, the process halts, and the remaining emails stay in the queue indefinitely.

While it’s possible to pause and resume the sending process, this doesn’t resolve the issue, as the campaign remains stuck at the same point. Other campaigns can still be sent without issues, but the affected campaign does not progress any further.

We’ve noticed that the problem might be related to unrecognized bounce events, such as:
• Bounce.Transient
• Bounce.SoftBounce
• Bounce.DnsError
• Bounce.Blocked
• Bounce.AutoResponder

Additionally, there are no relevant entries in the logs to help identify the cause or pinpoint problematic email addresses.

We’d greatly appreciate it if you could investigate this issue and provide guidance on how to resolve it. Thank you for your support!

Plugin Version

3.5.7 Pro

Craft CMS Version

5.5.4

PHP Version

8.3

[bencroker]

For example, if 1,000 out of 1,200 emails are sent, the process halts, and the remaining emails stay in the queue indefinitely.

Can you specify what you mean by halts? Does it fail? If so, can you please check the campaign-specific logs for errors?

What sometimes happens with Postmark is that they add email addresses to their suspension lists, and therefore sendouts fail because the API rejects those email addresses. See the note about Postmark at https://putyourlightson.com/plugins/campaign#bounce-complaint-handling

If that’s the case, you’ll need to mark the contact as blocked in Campaign, and then resuming sending should work. Sendouts fail after 3 attempts to at most 1 rejected contact by default, but you can configure this using the following config settings.

craft-campaign/src/config.php

Lines 86 to 90 in 0604651

	// The maximum number of times to attempt sending a sendout to a single contact before failing
	//'maxSendAttempts' => 3,
	// The maximum number of failed attempts to send to contacts that are allowed before failing the entire sendout
	//'maxSendFailuresAllowed' => 1,

[alexanderbuergin]

Thank you for your response.

We are sending batches of emails, and at a certain point, the sending process simply halts. What happens is that a new queue is created, and it runs until it reaches a specific number of emails sent, after which it stops. The campaign remains in the “Sending” status, but the queue stays stuck for days. We do not receive any error messages within Campaign, and even when checking the error logs in Campaign itself, there are no relevant entries.

The issue only occurs with one specific segment of our list. We have four segments in total, each containing approximately 600 to 1,000 addresses. For three of these segments, the sendout completes without any issues. However, when we send to the problematic segment, the process halts at a specific point as described.

I’ve attempted stopping the campaign, pausing it, editing it, and then resuming the sendout. When doing so, the system creates a new queue job, but the sending stops again at the exact same number of emails as before. We cannot identify the cause because neither the Campaign logs nor Postmark logs provide any useful information.

We are aware of Postmark’s bouncing issue and have already implemented a custom unsubscribe button in Postmark to handle this. In cases where an email address cannot be delivered, Campaign usually logs it. However, in this instance, there is no such indication. Our configuration settings are default, with “max send attempts” set to 1. We plan to increase the limits for the next sendout to see if it helps, but I doubt this will resolve the problem.

Unfortunately, due to data privacy concerns, we cannot provide a database copy. Would it be helpful if I recorded a video of the process during the next sendout so you can observe the issue in action?

[bencroker]

An error is likely being logged somewhere, you just need to track it down.