MIF JMSQSEQCONSUMER sends error notification on first retry attempt despite Maximum Try Count is 5

Expected Behavior

For a Sequential Outbound Queue configured with Maximum Try Count = 5, transient communication failures should be retried up to the configured maximum number of attempts before the transaction is considered a failed integration.

Integration Error Notification emails sent to the address specified in mxe.int.admintoemail should only be generated when the integration transaction has exhausted all configured retry attempts and is determined to be a final failure condition.

In the reported scenario, the outbound transaction receives an HTTP 502 Bad Gateway response on the first attempt, but succeeds automatically on a subsequent retry a few seconds later. Because the transaction ultimately completes successfully and never reaches a terminal error state, an administrator notification email should not be generated.

Why This Behavior Would Be Useful

The purpose of the retry mechanism is to automatically recover from temporary infrastructure issues such as:

• API Gateway interruptions
• Load balancer failures
• Temporary network connectivity issues
• Brief downstream application outages
• Transient HTTP 502, 503, or 504 responses

If an error notification is generated on the first failure attempt, before the retry mechanism has completed its work, administrators receive alerts for conditions that resolve automatically without any intervention.

This results in:

• False-positive alerting
• Alert fatigue for support teams
• Increased monitoring noise
• Unnecessary incident investigations
• Reduced confidence in integration error notifications

The more useful behavior is for email notifications to represent actionable failures that require attention, rather than temporary retryable conditions that the system successfully recovers from.