Download the PHP package graycore/magento2-cron-group-relocation without Composer

Magento 2 Cron Group Relocation

Magento Version Support

Ever have one slow cron job in the default group hold up every other job in that group, and try to move it somewhere else?

Then find it running twice a night — once in reports, and still once in default.

This package moves a cron job into a different group than the one its declaring module put it in, without running it twice.

Purpose

crontab.xml is additive. Magento\Cron\Model\Config\Converter\Xml keys its output [groupId][jobCode] and the DOM merge identifies /config/group/job by group id plus job name, so redeclaring an existing job code under a second group leaves it registered in both. There is no XML construct that removes a job from a group.

That makes a vendor module's group choice effectively final — even though group choice is what controls which jobs share a lock, a process, and a schedule look-ahead window. A single slow job in default can consume the window in which another job's schedule row had to be generated, and Magento only ever schedules forward, so that job is neither run nor marked missed. It silently does not exist for that cycle.

This package lets you put such a job in its own group, so its runtime is somebody else's problem.

Getting Started

This module is intended to be installed with composer. From the root of your Magento 2 project:

1. Download the package

2. Enable the package

3. Declare a destination group in your own module's etc/cron_groups.xml

4. Map jobs into it from your own module's etc/di.xml

5. Sequence your module after this one in etc/module.xml, so your arguments merge on top

6. Flush the config cache

Features

• Moves any cron job to any group, keyed by job code — no need to know which module declared it
• Never runs a job twice, unlike redeclaring it in crontab.xml
• Preserves the job's schedule, instance, method and config_path exactly as merged
• Preserves core_config_data schedule overrides — it intercepts downstream of Magento\Cron\Model\Config\Reader\Db, so the schedule actually in effect travels with the job
• Creates no group for a job that doesn't exist, so a disabled declaring module can't leave an empty group behind to be locked and schedule-generated against
• Idempotent, and a no-op when nothing is configured
• No database tables, no admin config, no cron jobs of its own

Upgrading

• Semver Policy