<p dir="auto">The following snippet does not produce an error:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="post analyzertest1
  {
    &quot;settings&quot;: {
        &quot;analysis&quot;: {
            &quot;analyzer&quot;: {
                &quot;my_analyzer&quot;: {
                    &quot;tokenizer&quot;: &quot;standard&quot;,
                    &quot;abracadabra&quot;: &quot;foo&quot;
                }
            }
        }
    }
  }"><pre class="notranslate"><code class="notranslate">post analyzertest1
  {
    "settings": {
        "analysis": {
            "analyzer": {
                "my_analyzer": {
                    "tokenizer": "standard",
                    "abracadabra": "foo"
                }
            }
        }
    }
  }
</code></pre></div>
<p dir="auto">We have a few open issues to do with analysis settings validation (eg <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="131365326" data-permission-text="Title is private" data-url="https://github.com/elastic/elasticsearch/issues/16451" data-hovercard-type="issue" data-hovercard-url="/elastic/elasticsearch/issues/16451/hovercard" href="https://github.com/elastic/elasticsearch/issues/16451">#16451</a>, <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="371576600" data-permission-text="Title is private" data-url="https://github.com/elastic/elasticsearch/issues/34604" data-hovercard-type="issue" data-hovercard-url="/elastic/elasticsearch/issues/34604/hovercard" href="https://github.com/elastic/elasticsearch/issues/34604">#34604</a>).  Adding some kind of general validation framework for analysis settings would be a huge improvement in terms of usability, and generally be in line with our efforts to be less lenient in what we accept.</p>
<p dir="auto">We've discussed in the past whether or not we should remove analysis configuration from index settings and make it a part of the mapping definition.  This would get us XContent validation for free, but it's a substantial change that has implications for other parts of the system, such as index templates.</p>
<p dir="auto">A simpler way forward would be to add an <code class="notranslate">acceptedSettings</code> parameter to the constructors of <code class="notranslate">AbstractTokenFilterFactory</code>, <code class="notranslate">AbstractCharFilterFactory</code> and <code class="notranslate">AbstractTokenizerFactory</code>, taking a list of settings that we expect to see, and throwing an error if the passed-in <code class="notranslate">Settings</code> object has any unrecognised keys.</p>