Method by name already exists in this class

[norgeindian]

We have a third party module, which has the following plugin definition:

    <type name="Magento\Elasticsearch\Elasticsearch5\SearchAdapter\Mapper">
        <plugin name="XXX::updateElasticQuery"
                type="XXX\YYY\Plugin\Elasticsearch\SearchAdapter\Mapper"/>
    </type>
    <type name="Magento\Elasticsearch\ElasticAdapter\SearchAdapter\Mapper">
        <plugin name="XXX::UpdateElasticQuery"
                type="XXX\YYY\Plugin\Elasticsearch\SearchAdapter\Mapper"/>
    </type>

As you can see, the plugin name, is the same for both classes.
Now the issue is, that in Magento 2.4.7-p3, these classes extend from each other:

class Magento\Elasticsearch\Elasticsearch5\SearchAdapter\Mapper extends \Magento\Elasticsearch\ElasticAdapter\SearchAdapter\Mapper

As soon as I now run setup:di:compile, I get the following error message:

 A method by name ____plugin_XXX__updateElasticQuery already exists in this class.                                                                     
  Class Magento\Elasticsearch\Elasticsearch5\SearchAdapter\Mapper\Interceptor generation error

When I deactivate this module here and let Magento create the plugins as usual, I don't get any error anymore.
So I think it would be awesome if a way could be found to handle situations like that.
Anyone an idea how to approach that?

[jambardnishvili]

I'm investigating this issue atm, it looks like it has the problem when plugin names are the exact same but the first letter is in the different casing, so for example in my testing it correctly run when trying to generate it with names:

XXX::UpdateElasticQuery
XXX::UpdateElasticQuery

But incorrectly when naming is:

XXX::UpdateElasticQuery
XXX::updateElasticQuery

So the issue is somewhere in the casing

[fsw]

Hi,

What is the default magento behaviour in this case? Are both plugins executed or does the later overrides the first one defined? If it is overridden does it also override it if same name is in different case ("foo" and "Foo")?

Names of variables and getters for plugins are generated from clean_name field generated in this method:

private function getPluginInfo(CompiledPluginList $plugins, $code, $className, &$allPlugins, $next = null)

So probably we need to add duplication check here and make this duplication check case insensitive.

[norgeindian]

@jambardnishvili , thanks, awesome investigation.
To be honest, I did not even see, that the names differ this way.
I actually thought they were exactly the same.
So thanks a lot for finding that.

[jambardnishvili]

Hi,

What is the default magento behaviour in this case? Are both plugins executed or does the later overrides the first one defined? If it is overridden does it also override it if same name is in different case ("foo" and "Foo")?

Names of variables and getters for plugins are generated from clean_name field generated in this method:

private function getPluginInfo(CompiledPluginList $plugins, $code, $className, &$allPlugins, $next = null)

So probably we need to add duplication check here and make this duplication check case insensitive.

Testing with default Magento.

It seems like both Interceptor's are generated in both cases, triggering wise it does seem to have weird side-effects maybe they are intended though 😆 , for example:

Case 1, when names are same but casing differs:

If i have two controllers which extend each other for example Index, ExtendIndex. and we have a plugin added with same name for each of them.

If i hit the Index endpoint, plugin is triggered only once, but if ExtendIndex is hit, then plugin is triggered twice.

Case 2, when names are exactly same with casing as well:

plugin in both Index, ExtendIndex controllers are only triggered once

Testing with the module.

Case 1, When casing is same:
It looks like only one Interceptor is generated and it is for IndexExtend.

Case 2, When casing differs
Then the origin error pops out that it can't generate the interceptor with the same name

[fsw]

I think plugins should be inherited so magento behavior seems correct (ExtendIndex has two plugins and Index only one) when casing is same I assume one plugin overrides the other and only one is called so magento is case sensitive here.

So guess we just need a fix for Case 2 (When casing differs).

[jambardnishvili]

This is my Xdebug result when inspecting how plugins are got for IndexExtend controller, so two plugins with different casing, most likely this is the point where we want to decide do we normalize names into lower string or not

[norgeindian]

@jambardnishvili, what would be the best fitting solution in your eyes?
Will be happy to prepare a PR, but first would like to discuss the direction and approach.
Maybe we simply define a different naming convention based on the casing, so that both results will be different in the end?

[fsw]

Hi @norgeindian @jambardnishvili,
After giving this some second thought I have a small dilemma here.

On one hand it would be cool if this module would be 100% compatible with Magento in all cases and using this will require just installing with composer and no code changes at all.

On the other hand case sensitivity seems like a negotiable feature that is erroneous and bad code in my opinion. For example in described issue I wonder if developer really wanted to add another plugin named UpdateElasticQuery or did he in fact wanted to replace plugin named updateElasticQuery. I would not be surprised if we found out that this is actually a potential bug in Elasticsearch and it works "by chance".

We could fix this issue by adding prefixes etc in such cases but in fact we will be adding complexity and overhead to generating interceptors only to allow such a marginal case "code smells".

I wonder if it would be in fact better to "fix" this by adding "Incompatibilities with Magento interceptors" section to README.

This section could say that if you see an error like "A method by name ___plugin* already exists in this class" your interceptors are depending on case sensitivity and you can fix this by changing plugin names.

As this is a build time issue and happens when running setup:di:compile this would be relatively easy to spot and fix and it could even point to a potential plugin bug that was not visible when using Magento interceptors. Developer is now forced to decide if he really wants to replace a plugin or add another.

What do you guys think?

[norgeindian]

@fsw , thanks for your thoughts on this issue.
I'm with you, this might be an absolute edge case, which happens only once every few years and like you say, there is a good chance, that the vendor of the module actually did this by mistake.
So yeah, if it's actually that complex to fix, let's maybe simply add it to the README and keep it like that, I agree.