For arlanix/notification 1.0.0

Troubleshooting

Everything the module logs goes to var/log/arlanix.log, under the channel arlanix_notification. The store owner's side of each problem is in the manual's troubleshooting.

setup:upgrade fails on RabbitMQ

setup:upgrade, or setup:db-schema:upgrade in a deploy, stops in Magento_Amqp's setup:

Error while checking if topic "arlanix.notification.deliver" is synchronous

The store's cache still holds the message queue topics as they were before the modules came, while the queue to declare on RabbitMQ is read from the modules: Magento finds a queue for a topic it does not know. It happens when the cache outlives the code, as a Redis cache the running site shares does during a deploy. Clean the config cache and run the upgrade again:

bin/magento cache:clean config
bin/magento setup:upgrade

In a deploy, clean it just before setup:db-schema:upgrade, so the upgrade reads the new release's config throughout. With Deployer's Magento recipe:

task('magento:upgrade:db:clean_config', function () {
    if (get('database_upgrade_needed')) {
        run('{{bin/php}} {{bin/magento}} cache:clean config');
    }
});
before('magento:upgrade:db', 'magento:upgrade:db:clean_config');

Any module that adds a queue topic meets it on such a deploy, not only these.

Deliveries wait on the queue

The admin says:

Arlanix Notifications: 3 notification(s) have waited more than 15 minutes to be sent. Nothing takes them off the message queue: start the consumer with bin/magento queue:consumers:start arlanix_notification_deliver, or check that cron runs the queue consumers (cron_consumers_runner) and the arlanix_notification cron group.

1. Check the consumer exists and runs:

   bin/magento queue:consumers:list | grep arlanix
   bin/magento queue:consumers:start arlanix_notification_deliver --max-messages=100
   

   If the second command sends them, the cron does not start the consumer. Either the cron itself does not run, bin/magento cron:run every minute, or app/etc/env.php keeps its consumer runner from it. Let it:

   'cron_consumers_runner' => [
       'cron_run' => true,
   ],
   

   With no cron_consumers_runner at all, it runs too. A consumers list in it names the only consumers it starts: add arlanix_notification_deliver to it. app/etc/env.php is read on every run: the next minute's cron starts the consumer.

2. With only_spawn_when_messages_available at 1, the default, the runner starts it only when messages wait, which is all it needs.

3. On RabbitMQ, the queue arlanix.notification.deliver has to be declared. Until it is, Magento's consumer runner fails on every run and starts no consumer of the store at all, and cron_schedule has for consumers_runner:

   NOT_FOUND - no queue 'arlanix.notification.deliver' in vhost '/'

   setup:upgrade declares it. A deploy that runs it only when setup:db:status finds the database behind, as Deployer's Magento recipe does, skips it after a deploy that failed past the schema, and never sees a RabbitMQ that lost its queues. Declare it, whatever the status:

   bin/magento setup:db-schema:upgrade
   

   A deploy can declare the queues on every run by calling Magento\Framework\Amqp\TopologyInstaller::install(), as Magento_Amqp's setup does; declaring a queue that exists changes nothing. The deliveries published while the queue was missing were lost on the way: the cron puts them back an hour after they were published.

A delivery left retry past its time means the arlanix_notification cron group does not run: bin/magento cron:run --group=arlanix_notification.

A delivery failed

The message's page in the Message Log, and the subscription's Last delivery, say what the server answered:

Telegram, Slack and Discord:

After fixing it, Retry now on the message's page puts the failed deliveries back at once, with their attempts started over.

A message has no deliveries

The Message Log shows No subscribers when no subscription of the topic is active and takes the message's severity. A topic that is switched off logs nothing: the publish is dropped with an info line in the log, written when Stores > Configuration > Arlanix > Logging > Log level is Info or Debug. A topic id that does not exist is logged as a warning naming the message and its source.

A digest was not formed

Messages merge only within one batch. Under the cron runner a batch is what waited when the minute's run began; a consumer that runs on reads every 10 seconds. With several consumers, each merges its own batch. A digest holds up to 25 different messages (DigestBuilder::MAX_ENTRIES): a subscription's batch with more goes as several.

A rule does not send

1. The rule and its topic are active, and the topic has a subscription that takes the rule's severity: No subscribers in the Message Log otherwise.
2. The event is emitted at all. An event of a module that is not enabled, such as Magento_Review's, is not offered. Sales events are emitted after the commit: a test that rolls its transaction back emits nothing.
3. The conditions match what was emitted. Preview renders with the declared samples, not the event's data; log the data in a test, or loosen a condition to see it send.
4. A template naming a field the event does not have is refused when the rule is saved; a field that is empty renders empty, or as default: says.

A rule's message is published as any other: the queue, the consumer and the retries above all apply.