#33386 Fix triggers management issue during setup:upgrade

[Nuranto]

Description (*)

During setup:upgrade, the Indexer\Setup\Recurring class unconditionally drops and recreates all database triggers for every scheduled indexer by calling unsubscribe()/subscribe() in a loop. This acquires exclusive table locks even when no trigger changes are needed, causing unnecessary downtime on large installations.

This PR:

• Replaces the per-indexer unsubscribe()/subscribe() loop with a single call to TriggerCleaner::removeTriggers(), which only recreates triggers whose SQL statements have actually changed.
• Fixes stale trigger detection in TriggerCleaner by extracting logic into a shouldUpdateTrigger() method that performs a normalized full-statement comparison instead of a partial str_contains check. This also detects obsolete statements from removed views.

Fixed Issues (if relevant)

1. Fixes setup:upgrade is changing indexer mode to save from schedule slowing it down immensely #33386

Manual testing scenarios (*)

1. Run bin/magento setup:upgrade on an instance with multiple scheduled indexers and verify triggers are only recreated when their SQL actually differs from the DB state.
2. Remove an indexer module (e.g. disable a module that registers an mview), run setup:upgrade, and verify that stale trigger statements from the removed view are cleaned up.
3. Run setup:upgrade twice in a row with no configuration changes and verify no triggers are dropped/recreated on the second run (no unnecessary exclusive locks).

Questions or comments

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @Nuranto. 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.

[Nuranto]

@magento run all tests

[engcom-Hotel]

@magento run all tests

[engcom-Hotel]

Hello @Nuranto,

Thank you for the contribution!

It seems that due to the recent PR changes, the database compare test has started failing. Please look into this issue.

[engcom-Charlie]

@magento run all tests

[engcom-Charlie]

Hello @Nuranto,

Thank you for the contribution!

It seems that due to the recent PR changes, the database compare test has started failing. Please look into this issue.

@engcom-Hotel, In order to fix the database compare test failure, I have updated the fix for "Migrating the change-log tables during setup:upgrade without rebuilding the triggers. The test failure is fixed now. Moving it to Review again.

[engcom-Hotel]

Failed tests seems flaky to me or does not related to this Pr. Hence confirming this PR.