Troubleshooting: Configured sort order not reflected in results

Symptom

A query pipeline applies a sort parameter, and the response header shows the sort and fq parameters are present and correct — yet one or more documents appear out of the expected sort order. A common variant: a single high-priority document lands far down the list, below lower-priority documents, while the rest of the results are ordered correctly.

Because the sort and filter parameters are visibly applied in the response header, this is easy to misdiagnose as a Solr issue or a pipeline regression. Before pursuing those, rule out a business rule first.

Likely cause: a Pin business rule overriding sort

A Pin business rule (Pinned action) sticks a specific document to a fixed position in the results regardless of the configured sort. Pin rules are response-rewriting rules: they are matched by the Apply Rules stage and applied to the Solr response by the Modify Response with Rules stage, which runs after the Solr Query stage has already sorted the results. (The Modify Response with Rules stage requires an enabled Apply Rules stage and has no configuration keys of its own — it is simply enabled or disabled.) When a pin rule matches, the pinned document is relocated to its configured position, overriding the sort for that document only. Other documents keep their sorted order, which produces the "one document stranded out of place" signature.

This is intended behavior. The Pinned action sticks a document to a specific position in the search results, so the pinned document lands at its configured position regardless of the sort order for the rest of the results.

How to diagnose

1. In Query Workbench, create a temporary pipeline that mirrors the affected query pipeline.
2. Run the reproducing query with the Modify Response with Rules stage enabled, then again with it disabled.
   • If the misordering disappears when the stage is disabled, a response-rewriting rule (typically a Pin) is the cause. The "enabled" result matches what is seen in the live environment.
3. Identify the matching rule in the Business Rules editor (or Predictive Merchandiser / Commerce Studio). Search the rules for the affected document's id or for a Pin action whose trigger conditions match the query.

Note that toggling the Modify Response with Rules stage disables only response-rewriting rules (such as pin, banner, and redirect). Query-rewriting rules applied by the Apply Rules stage are not affected by this toggle.

Alternate way to diagnose

1. Add "lw.rules.debug=true" to the URL request sent.
2. The returned JSON will have a "applicable_rules" section showing what rules fired:

Analyzing the rules fired, may aid in determining if the issue is caused by a rule, and which specific rule is involved.

Resolution

Locate the Pin rule that targets the affected document and its trigger conditions, and remove or correct the pinned position so it no longer conflicts with the intended sort. Editing rules requires access to the Business Rules editor (or Predictive Merchandiser / Commerce Studio) for the environment. Test changes in a non-production environment that carries the same rule set before applying them to production.

Key points

• A visible, correct sort in the response header does not guarantee the final order — response-rewriting rules run after Solr sorts.
• Pin rules force a fixed position and override sort for the pinned document(s) only, so most results remain correctly ordered.