Resolving unexpected spellcheck behavior caused by query rewrites

Issue

Solr spellcheck suggestions are missing or incorrect when used in conjunction with Fusion query rewriting features such as synonym expansion or business rules. This often results in spellcheck suggestions that do not match the user’s original query input.

Diagnosis

To determine if this issue is present:

• Verify that Solr spellcheck is properly configured in solrconfig.xml.  See https://solr.apache.org/guide/solr/latest/query-guide/spell-checking.html for details.

• Inspect the value of the q parameter in the request sent to Solr.    You'll have to view the response in JSON, and look for the responseHeaders section:

  "responseHeader" : { 
  
      "params" : { 
   
        "origDefType" : "edismax", 
        "orig_q" : "(annuity^2 OR annuities) onboardin", 
  
        "rules_item_W5fWPf8rQA_0" : "https://domain.com/sfc/0683g00000GfwAB.html", 
  
        "rules_ordered_q" : "({!term f=uri v=$rules_item_W5fWPf8rQA_0})^=0.001", 
  
        "defType" : "lucene", 
  
        "q" : "({!lucene v=$rules_ordered_q}) OR (-({!lucene v=$rules_ordered_q}) {!edismax v=$orig_q})", 
   
      }, 
    },

• If the q parameter contains rewrite logic or expanded synonyms,  Solr’s spellcheck is likely working on the rewritten value of q, not the original user query.  Solr may be generating suggestions like:

  "spellcheck" : { 
      "suggestions" : [ [ "lucene", { 
        "numFound" : 5, 
        "startOffset" : 39, 
        "endOffset" : 45, 
        "origFreq" : 0, 
        "suggestion" : [ { 
          "word" : "luciene", 
          "freq" : 46 
        }, { 
          "word" : "lucena", 
          "freq" : 8 
        }, { 
          "word" : "lucerne", 
          "freq" : 8 
        }, { 
          "word" : "lucente", 
          "freq" : 6 
        }, { 
          "word" : "lucine", 
          "freq" : 2 
        } ] 
      } ] ], 
      "correctlySpelled" : false, 
      "collations" : [ ] 
    },

• Check whether the request includes a spellcheck.q parameter. If not, Solr uses the rewritten q value for spellchecking by default.

Environment

Any Fusion version with business rewrite capabilities.

Cause

When Fusion query pipelines apply business rules (via the "Apply Rules" stage) or synonym expansions (via the "Text Tagger" stage), they alter the q parameter before the query is passed to Solr. Solr then runs its spellcheck component on this rewritten version of q.

This behavior can lead to:

• Irrelevant or misleading spellcheck suggestions

• Absence of suggestions when expected

• Confusion caused by combined query syntax (e.g., inclusion of boosts, parentheses, or logical operators)

Resolution

To ensure Solr spellcheck operates on the original user query and not the rewritten version, set the spellcheck.q parameter explicitly before the Solr Query stage.

Option 1: Add spellcheck.q directly in the application request

Modify the application code to send both q and spellcheck.q with the same value, where spellcheck.q holds the original user input.

Example query:

q=annuity+onboardin&spellcheck.q=annuity+onboardin

This avoids any interaction with pipeline rewrite stages.

Option 2: Set spellcheck.q early in the query pipeline

Use an "Additional Query Parameters" stage early in the pipeline to copy the q value to spellcheck.q.

• Use a condition to apply this only when spellcheck.q is not already set.

• This still bypasses any rewrites that occur later in the pipeline.

Option 3: Dynamically set spellcheck.q based on orig_q or q

Use a JavaScript stage near the end of the pipeline to create the spellcheck.q parameter based on either orig_q or q, depending on availability.

Sample JavaScript stage:

function(doc, ctx) {
  var orig = ctx.getParam("orig_q");
  var q = ctx.getParam("q");

  if (orig != null && orig.length > 0) {
    ctx.setParam("spellcheck.q", orig);
  } else if (q != null && q.length > 0) {
    ctx.setParam("spellcheck.q", q);
  }

  return doc;
}

Place this stage immediately before the "Query Solr" stage. This will allow the Solr spellcheck to operate with some of the query rewrites (because they're impact will be included in orig_q), while bypassing some of the business rule updates to q.