Skip to content

Add queue:config:status for message queue topology sync detection - #41254

Open
ajith107 wants to merge 1 commit into
magento:2.4-developfrom
ajith107:bugfix/38225-queue-config-status
Open

Add queue:config:status for message queue topology sync detection#41254
ajith107 wants to merge 1 commit into
magento:2.4-developfrom
ajith107:bugfix/38225-queue-config-status

Conversation

@ajith107

Copy link
Copy Markdown
Contributor

Summary

  • Adds queue:config:status (exit code 2 when setup:upgrade is required) without changing setup:db:status, per maintainer feedback on Message Queue Changes Tracking in setup:db:status Command #39698.
  • Compares topology queues via Topology\ConfigInterface::getQueues() to the MySQL queue table using missing-only array_diff (legacy DB rows ignored).
  • Refactors Magento\MysqlMq\Setup\Recurring to share the same synchronizer so status and upgrade stay aligned.

Related

Manual testing scenarios

  1. bin/magento setup:upgrade then bin/magento queue:config:status → exit 0
  2. Add a new binding/destination in a module queue_topology.xml
  3. bin/magento cache:flush then bin/magento queue:config:status → exit 2, lists missing queue
  4. Confirm bin/magento setup:db:status still exit 0 (by design)
  5. bin/magento setup:upgrade then queue:config:status → exit 0

Test plan

  • Unit tests for QueueConfigSynchronizer, ChangeDetector, QueueConfigStatusCommand, Recurring
  • Manual local verification of exit codes 0 → 2 → 0
  • Magento CI: Unit Tests, Static Tests

Notes for deploy tooling

Call queue:config:status in addition to setup:db:status when deciding whether to run setup:upgrade.

Deploy tooling that relies on setup:db:status misses message-queue topology
changes applied only during setup:upgrade. Add a dedicated status command
and share missing-queue detection with MysqlMq recurring setup.

Fixes magento#38225
@m2-assistant

m2-assistant Bot commented Sep 12, 2026

Copy link
Copy Markdown

Hi @ajith107. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

  • @magento run all tests - run or re-run all required tests against the PR changes
  • @magento run <test-build(s)> - run or re-run specific test build(s)
    For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:
  1. Database Compare
  2. Functional Tests CE
  3. Functional Tests EE
  4. Functional Tests B2B
  5. Integration Tests
  6. Magento Health Index
  7. Sample Data Tests CE
  8. Sample Data Tests EE
  9. Sample Data Tests B2B
  10. Static Tests
  11. Unit Tests
  12. WebAPI Tests
  13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.


For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

@ajith107

Copy link
Copy Markdown
Contributor Author

@magento run all tests

@lbajsarowicz

Copy link
Copy Markdown
Contributor

@ajith107 your queue:config:status here made me look at what a user does after it reports exit 2, and the only answer today is a full setup:upgrade. I raised #41255 for that gap and opened #41256 adding setup:queue:upgrade as the apply side.

The two are independent — #41256 does not touch setup:db:status or your command, and needs nothing from this PR to merge. Detection and apply seem worth reviewing as a pair, so flagging it here rather than in parallel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Message queue topology is not considered in setup:db:status check

2 participants