[cancan101]

Changes in this pull request

Fixes pimcore/platform-version#714

When another process holds the command's lock, SequentialProcessQueueCommand::execute() prints The command is already running. and calls exit(1). exit() inside Command::run() ends the process before the Application dispatches console.terminate. As a result, listeners never see the run end: a cron monitor (Sentry Crons) that closes its check-in on terminate reports every overlapping cron run as a timeout during a long import. The command also can't be run in-process.

It now prints the same message and returns Command::SUCCESS. The run had nothing to do because another process is already working through the queue, and Symfony's LockableTrait example handles the same case the same way. Nothing else changes; the lock was never acquired on this path, so there is nothing to release.

datahub:data-importer:process-queue-parallel reaches the same exit(1) through Pimcore\Console\Traits\Parallelization, which is fixed in pimcore/pimcore#19622 (pimcore/platform-version#713). No change is needed in this repository for that one.

How to reproduce

1. Start datahub:data-importer:process-queue-sequential while another run holds its lock (or hold the lock yourself: Pimcore::getContainer()->get(LockFactory::class)->createLock('datahub:data-importer:process-queue-sequential', 60)->acquire(false)).
2. Run the command with a console.terminate listener, or in-process with setAutoExit(false).

Before: the process exits with status 1 inside execute(), and the listener never runs. After: ERROR: The command is already running., exit code 0, and the listener runs.

Additional info

Checked on our install (data-importer 2.4.5 with this change applied as a patch; the code is identical to 2026.3). The command runs through a real Application while a FlockStore lock with its name is held. Before the change the process exits with status 1 and console.terminate is never dispatched. After it, execute() returns 0, console.terminate is dispatched with exit code 0, and the queue is not touched. I haven't added a Codeception test: the suite needs the full Pimcore stack, and the path is a single return.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

🟢 Approval recommended

No active review issues are recorded for the focused lock-contention change intended to preserve Symfony’s command lifecycle.

No open issues 🎉

What changed in this PR

The PR addresses overlapping sequential queue runs exiting PHP before Symfony can dispatch console.terminate. It fixes the command-owned early-exit path rather than working around it in monitoring code (src/Command/SequentialProcessQueueCommand.php:60–65).

Changes:

• Replaces exit(1) with return self::SUCCESS when the lock is unavailable.
• Preserves the existing message and adds a comment explaining why normal command completion matters.

The observable compatibility change is intentional: lock contention now returns status 0 instead of terminating with status 1; the method signature is unchanged. The fix is local to the sequential command; parallel-command handling is outside this diff.

Runtime event dispatch was not independently verified. No automated regression test or documentation/changelog file is included; the PR description reports manual verification and explains the behavior change.

File	Description
src/​Command/​SequentialProcessQueueCommand.php	Returns success on lock contention so Symfony can complete the command lifecycle.

_{Review effort: Balanced}