Flush scope config cache after encrypting the client secret, so when …

[hostep]

…the TransferFamiliesAndCategoriesToNewFormatPatch patch needs it, it's no longer the old unencrypted value from cache.

We are upgrading and old Magento 2.3.6 shop to 2.4.6 and in the process are also upgrading akeneo/module-magento2-connector-community from 101.8.2 to 104.3.2

However, we've been running into this error the first time we execute bin/magento setup:upgrade:

Unable to apply data patch Akeneo\Connector\Setup\Patch\Data\TransferFamiliesAndCategoriesToNewFormatPatch for module Akeneo_Connector. Original exception message: Parameter "client_id" is missing or does not match any client, or secret is invalid (see https://api.akeneo.com/php-client/exception.html#unprocessable-entity-exception)

After some debugging, this is because:

1. First the patch EncryptApiSecret is being executed which fetches the unencrypted client secret, encrypts it and writes it back to the database
2. After that, the TransferFamiliesAndCategoriesToNewFormatPatch runs and tries to create an AkeneoClient, but in doing this, it fetches the old unencrypted client secret from config cache, instead of using the newly encrypted client secret from the database. And then can't create an akeneoclient object because the wrong secret is used.

These patches were introduced in the codebase not at the same time, so it makes sense almost nobody ran into this problem yet, if you regularly update the module to the latest version, it should be no problem. But if you do a big upgrade and both patches have to run at the same time, you'll run into this problem.

I've added:

• a call to $this->scopeConfig->clean(); after the encrypted client secret is written to the database, so the config caches are flushed, so the next time this client secret is fetched, it doesn't come from an outdated config cache
• an explicit dependency from TransferFamiliesAndCategoriesToNewFormatPatch on EncryptApiSecret so it's guaranteed that the order in which those patches run are correct. This wasn't a problem at the moment, because I think if there are no dependencies defined, Magento will execute those in alphabetical order, which by accident was the correct order, but I'd like to make the sort order more explicit by defining dependencies correctly.