[Fixed: #31396] Data/Schema Patches getAliases() not working as expected

[Usik2203]

Description (*)

This PR fixed next issues #31396 #23031

Fixed Issues (if relevant)

#31396
#23031

Testing Scenario

1. New patch was created \Atwix\DataPatchTest\Setup\Patch\Data\ExampleDataPatch and successfully applied.

2. This patch was renamed to Atwix\DataPatchTest\Setup\Patch\Data\ChangedExampleDataPatch and was added Alias

3. run bin/magento se:up

Actual result

Only \Atwix\DataPatchTest\Setup\Patch\Data\ExampleDataPatch was applied
I didn't see errors in console after steps 2. and 3.

[m2-assistant]

Hi @Usik2203. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ 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

ℹ️ Please run only needed test builds instead of all when developing. Please run all test builds before sending your PR for review.

For more details, please, review the Magento Contributor Guide documentation.

⚠️ According to the Magento Contribution requirements, all Pull Requests must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of Pull Requests happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[Usik2203]

@magento run all tests

[rogyar]

Hi @Usik2203. Thank you for your contribution.
Please, check the failing tests.

[Usik2203]

@magento run all tests

[Usik2203]

@magento run all tests

[Usik2203]

@magento run all tests

[Usik2203]

Hi @rogyar
Failed tests were fixed
Thanks!

[multipasko]

This kind of fixes the issue but I see a problem here.
So let's assume the patch has renamed and now it is under different path and with Alias to the previous one.
It will not get applied again, there will be no new entry to patch_list for the renamed patch.

But for someone who never applied the old path patch, it will get applied. Which is good.
But they will get the entry in the patch_list with the new path (new patch_name).

So there will be not consistency in terms of the path_list table.
One may have the old patch_name and somebody else the new patch_name.

I guess for someone who has the new patch_name it will be better, as the patch applier will not check the list of patches against the aliases?

[djacques4gorilla]

@Usik2203 I don't see how this will work if you have more than one alias. This line will cause the function to return on the first test, no matter what, when it should only return if it finds an alias that is applied (and then default to false if none have been installed).
cc: @rogyar

[djacques4gorilla]

@Usik2203 We should still also loop over every alias and mark them as applied. In the case where a patch file is renamed (e.g. changing the namespace of a module), if we install the new version and only mark the new name as installed, rolling back to before the change will result in the same patch applying a second time. If we mark all aliases as installed, then it will prevent that from happening.