# run-as-root/magento2-message-queue-retry

> Provides message queue retry processing functionality via RabbitMQ's dead letter exchange.

`composer require run-as-root/magento2-message-queue-retry`

Canonical URL: https://packagento.com/run-as-root/magento2-message-queue-retry

## At a glance

- **Vendor**: run-as-root (https://packagento.com/run-as-root.md)
- **Latest version**: 3.0.2 — released 2025-10-15
- **Pricing**: Free
- **Package type**: Magento 2 module
- **Status**: active, accepting new buyers

## Installation

Packagento is licence-gated, so even free packages need a licence on a project before Composer can resolve them.

1. **Sign in or create an account** at https://packagento.com/customer/account/.

2. **Add the package to your account.** Open https://packagento.com/run-as-root/magento2-message-queue-retry and complete the free checkout. A licence is minted automatically.

3. **Create or pick a project, then activate the licence on it.**
   - Projects represent the Magento installs you deploy to. Manage them at https://packagento.com/projects/.
   - Activate the new licence on the project you'll deploy this package to. Activation is what generates the Composer credentials scoped to that project.

4. **Add the project credentials to your Magento codebase.**

   Grab the project's public + private key from https://packagento.com/projects/ (open the project, then its Credentials tab), and add them to `auth.json`:

   ```json
   {
     "http-basic": {
       "packagento.com": {
         "username": "ppk_live_...",
         "password": "psk_live_..."
       }
     }
   }
   ```

   Add the Packagento Composer repository to `composer.json`:

   ```json
   {
     "repositories": [
       { "type": "composer", "url": "https://packagento.com" }
     ]
   }
   ```

5. **Install and apply.**

   ```bash
   composer require run-as-root/magento2-message-queue-retry:*
   bin/magento setup:upgrade
   bin/magento setup:di:compile
   bin/magento cache:flush
   ```

## What it does

Provides message queue retry processing functionality via RabbitMQ's dead letter exchange.

## README

![Magento 2](https://img.shields.io/badge/Magento-2.5.*-orange)
![PHP](https://img.shields.io/badge/php-8.1-blue)
![packagist](https://img.shields.io/badge/packagist-f28d1a)
![build](https://github.com/run-as-root/magento2-message-queue-retry/actions/workflows/test_extension.yml/badge.svg)

## run-as-root/magento2-message-queue-retry

It gives the possibility to process the same queue message more than once,
utilizing The RabbitMQ's [dead letter exchange](https://www.rabbitmq.com/dlx.html)  feature.

### Table of Contents
- [Prerequisites](#prerequisites)
- [Installation](#installation)
- [Features](#features)
- [How it works](#how-it-works)
- [Configuration](#configuration)
- [Skipping the retry](#skipping-the-retry)
- [Exploring a real scenario](#exploring-a-real-scenario)
- [License](#licence)

---

### Prerequisites

- Magento 2.4.5 or higher
- PHP 8.1 or higher
- RabbitMQ

To be able to use this module, you have to manually configure the dead letter exchange(s) for the queue(s) you want to enable the retry mechanismm through the `queue_topology.xml` file.
An example will be given in the [Configuration](#configuration) section.

Other requisite is that your exchanges have to have a relation from one exchange to only one topic and queue,

For example:

![topology](docs/queue-requirement.png)

### Installation

To install the module via composer:
```bash
composer require run-as-root/magento2-message-queue-retry
```

To enable the module:
```bash
bin/magento module:enable RunAsRoot_MessageQueueRetry
```

---

### Features

- Toggle activation
- Configure the retry limit for a queue
- Admin grid to manage the messages with the retry limit reached
    - Requeue the failed messages to their origin queue
    - Delete the message
    - Download the message body

---
### How it works

The default Magento's consumer behavior is to reject the message when an exception is thrown during the consumer's execution.
If you use a standard configuration for the queue (without a dead-letter exchange), the message will be discarded and not processed again.

This behavior will change a bit with this module. It will introduce an extra step that will check if the message has reached your retry limit,
if so, it will be discarded from RabbitMQ and sent to the `run_as_root_queue_error_message` Mysql table and stay there until manual management through the admin panel.

If the message has not reached the retry limit, it will be rejected, and RabbitMQ will send it to the dead letter exchange. The message will be routed automatically to the "delay" queue and stay there until de TTL time is reached.
After the TTL time is reached, the message will be returned to its original queue.

The diagram below illustrates both approaches:

![img.png](docs/flow.png)

In the admin panel a new grid will be available to manage the messages that have reached the retry limit:

Path: RunAsRoot > Manage Messages

![img.png](docs/messages-grid.png)

The grid colums:

- **Topic name**: The name of the topic that the message belongs to
- **Total retries**: The total number of times the message has been processed
- **Failure Description**: The exception message that was thrown during the processing of the message
- **Message Body**: The original message body, it can be downloaded as a file and it is in JSON format.

The grid actions:

- **Requeue**: It will send the message to the original queue
- **Download**: It will download the message body content as a JSON file

The grid also has a mass action to delete or requeue the selected messages.

Is possible to configure the ACL for each action in the grid and the module configuration:

![img.png](docs/acl.png)

---

#### Configuration

Two steps are necessary to configure the retry for a queue:
1. Configure the dead letter exchange
1. Declare the retry limit xml configuration
1. Enable the message queue retry admin configuration 

##### 1. Configuring the dead letter exchange

Let's imagine a scenario that the `erp_order_export` queue already exists in your project and to simplify the example the topic name, exchange name and queue name are the same: `erp_order_export`.

We need to change these two files in order to declare and configure the delay queue:
- `communication.xml`
- `queue_topology.xml`

**The current queue configuration are like this**:

`etc/communication.xml`:

```xml
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Communication/etc/communication.xsd">
    <topic name="erp_order_export" request="string"/>
</config>
```

`etc/queue_topology.xml`:

```xml
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework-message-queue:etc/topology.xsd">
    <exchange name="erp_order_export" connection="amqp" type="topic">
        <binding id="erp_order_export" topic="erp_order_export" destinationType="queue" destination="erp_order_export"/>
    </exchange>
</config>
```

**You have to change it to**:

`etc/communication.xml`:

```xml
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Communication/etc/communication.xsd">
    <topic name="erp_order_export" request="string"/>
    <topic name="erp_order_export_delay" request="string"/>
</config>
```

_(README truncated for .md surface. Full README on https://packagento.com/run-as-root/magento2-message-queue-retry.)_

## Recent Versions

| Version | Released |
|---|---|
| 3.0.2 | 2025-10-15 |
| 3.0.1 | 2024-02-20 |
| 3.0.0 | 2024-02-02 |
| 2.1.1 | 2023-05-16 |
| 2.1.0 | 2023-05-15 |
| 2.0.3 | 2023-04-26 |
| 2.0.2 | 2023-04-18 |
| 2.0.1 | 2023-04-14 |
| 2.0.0 | 2023-04-13 |
| 1.1.0 | 2023-04-11 |

Showing 10 of 11 versions. Full release history on https://packagento.com/run-as-root/magento2-message-queue-retry.

## Dependencies

### Require

| Package | Constraint |
|---|---|
| magento/framework | ~103.0.5 |
| magento/framework-amqp | ~100.4.3 |
| magento/module-backend | ~102.0.5 |
| magento/module-config | ~101.2.5 |
| magento/module-ui | ~101.2.5 |
| php | ^8.1 |
| php-amqplib/php-amqplib | ^v3.2.0 |

### Require (dev)

| Package | Constraint |
|---|---|
| bitexpert/phpstan-magento | ^0.29.0 |
| magento/magento-coding-standard | * |
| pdepend/pdepend | ^2.13 |
| phpcompatibility/php-compatibility | ^9.3 |
| phpmd/phpmd | ^2.13 |
| phpstan/phpstan | ^1.10 |
| phpunit/phpunit | ~9.5.20 |
| sebastian/phpcpd | ^6.0 |
| slevomat/coding-standard | ^8.8 |
| squizlabs/php_codesniffer | ~3.7.0 |

## Quality

Latest release (3.0.2) fails the Packagento QA pipeline. Verdicts below are per-cell (Magento line × PHP version) for the matrixed tools, and run-once for the static / security tiers.


### Compatibility

Each Magento line is installed on its supported PHP versions, then the module is built (DI compile + static-content deploy). Cells show passed / failed / untested; staircase gaps render as `–`.

| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | Pass | Pass | – | – |
| 2.4.8 | – | Pass | Pass | – |
| 2.4.9 | – | – | Pass | Pass |


### Code Quality

Advisory checks against the module's source. Never affect the Compatibility verdict — a phpcs finding can't make a module incompatible.

#### Static Analysis

Coding standards (phpcs), mess detection (phpmd), copy-pasted code (cpd), PHP cross-version compatibility, composer.json validity. Each runs once for the whole module.

| Tool | Status | Findings | Summary |
|---|---|---|---|
| PHPCS | Fail | 230 | 20 errors, 210 warnings (ruleset: Magento2) |
| PHPMD | Fail | 5 | 5 rule violations (MissingImport:5) |
| Cpd | Warning | 1 | 1 duplicated chunk spanning 22 total lines (min-lines=5, min-tokens=70) |
| Composer validate | Pass | 0 |  |

#### PHPStan

Type-checks the module against a real Magento install. Re-runs per Magento + PHP version because resolvable symbols differ between releases.

| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | Pass | Pass | – | – |
| 2.4.8 | – | Pass | Pass | – |
| 2.4.9 | – | – | Pass | Pass |


### Tests

Unit and integration suites run per Magento + PHP cell. Test failures speak to the module's behaviour, not its compatibility with a line, so they're reported here separately.

#### Unit Tests

| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | Error | Error | – | – |
| 2.4.8 | – | Error | Error | – |
| 2.4.9 | – | – | Error | Error |

#### Integration Tests

| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | N/A | N/A | – | – |
| 2.4.8 | – | N/A | N/A | – |
| 2.4.9 | – | – | N/A | N/A |


### Security

Dependency-advisory audit (composer audit) plus a source malware scan. A malware detection fails the version outright.

| Tool | Status | Findings | Summary |
|---|---|---|---|
| Composer audit | Fail | 23 | 23 advisories (high:16, low:3, medium:4); 16 high+, 4 medium/unknown, 3 low |
| Malware scan | Pass | 0 |  |

## Licence and pricing

Free. A licence is still minted on checkout and bound to your project for Composer access — no payment step.

Refundable within 14 days of first purchase via https://packagento.com/account/refunds/.

## Install via Claude Code or any MCP client

The Packagento MCP server can run the licence + project + Composer steps above in one tool call:

```
purchase_and_install_packages(
  composer_names=["run-as-root/magento2-message-queue-retry"],
  project_id="proj_xxx"
)
```

This handles cart, checkout, licence minting, project activation, and writes auth.json credentials. Connect a client with `claude mcp add packagento https://mcp.packagento.com`. Full setup at https://packagento.com/docs/mcp-setup.

## Vendor

run-as-root is a Magento 2 vendor on Packagento. See https://packagento.com/run-as-root.md for their full catalogue.

