Pinging @elastic/es-search (Team:Search)

@martijnvg this is not related to highlighting, instead analysis. Hence correct tag should be ::Search/analysis

I am interested in contributing - could somebody give me any useful pointers to be able to pick this issue up? I have gone through the readme(s)
@amitmbm

Hello @ShailyTyagi I believe https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/index/analysis/AnalysisRegistry.java is where we load the analyzers/normalizers/etc configured in the index settings. There we look at type and name but we seem to be silently ignoring any additional parameter, while we would like to instead throw exception whenever an unsupported parameter is provided.

Hi @javanna @amitmbm , I found it interesting and was looking into it, and it seems like CustomAnalyzerProvider assigns the settings without validating. How should I proceed? I don't see any module being used to validate analyzer settings.

    public CustomAnalyzerProvider(IndexSettings indexSettings, String name, Settings settings) {
        super(indexSettings, name, settings);
        this.analyzerSettings = settings; // {"bar":"foo","foo":"bar","tokenizer":"standard","type":"custom"}
    }

@javanna would you be able to guide @EverWinter23 and @ShailyTyagi here, At first look it doesn't seems to be a small code change, but I might be completely wrong here.
Also would be more than happy to contribute here.

@amitmbm Any suggestions on how to move forward with it?

@EverWinter23 Sorry I wouldn't be able to help here, I guess someone from Elastic would be the best to provide input here

@javanna its been quite sometime, and a few users are willing to work on the issue, would be great if community can get some pointers on what needs to be done here.

thanks for the ping @amitmbm !

I am not super familiar with this area, but I had a look and while it may look simpler to just validate that only supported keys are used when parsing the analysis settings, we currently have no way to determine which keys are supported by which analyzer/filter/etc, which is complex especially given that custom components can be plugged in.

It all starts at AnalysisRegistry where we read settings from a map , from which we read the type and then delegate to the available provider the parsing of its corresponding settings. In other places we have a contract that when a setting is read from the map it is removed, so that at the end we can verify that there are no unsupported parameters left which were provided in the request. This becomes though quite a big infra change. Maybe instead of requiring changes to all of the providers, we could wrap the settings into a settings implementation which removes at get transparently, but that means that the same parameter can't be read multiple times. @romseygeek do you have thoughts on this? Could you double check that I am not missing anything?

can any one help me to find out issues I am new to Open Source and want to find my first issue how can I find

Hi,
I am new to open-source this is my first open-source project i am checking and looking forward to start making contributions to it, if anyone can mentor me ,it will be very helpful for me, would like to work on this issue!

Thanks.