Repository navigation
SOLR-18624: Fix flaky ordering assertions in TestMultiWordSynonyms.testPf - #5294
Draft
nick-boss-tech wants to merge 2 commits into
Draft
nick-boss-tech wants to merge 2 commits into
nick-boss-tech wants to merge 2 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 AI text below 🤖 (posted on behalf of Nick Shanin)
Draft status is due to Nick Shanin's open-PR cap; the change is complete and ready for review.
https://issues.apache.org/jira/browse/SOLR-18624
What happens today
TestMultiWordSynonyms.testPfis flaky because it expects a fixed order for documents with equal scores. Thetropical cyclone foorequest expects document 10 first, although all four matches can have the same score. Its two-word phrase boosts aretropical cycloneandcyclone foo. The first matches every document through the synonymbar; the second matches none. Document 10 has no score advantage, so a change in index document order can fail the assertion.What this change does
The test checks scores and phrase boosts while allowing tied results in any order. The initial requests must show that
bf=boost_dchanges scores, and the phrase requests must show that a close phrase match can outweigh that boost. For reversedbar foo, slop zero must leave documents 10 and 13 tied, while slop two must make document 10 score higher. The final request checks all four IDs and both expected phrase boosts without requiring document 10 first. Test changes.Proof
Linux verification at 0af4f5b
Verified November 5, 2026, with JDK 21 and Gradle 9.7.0:
TestMultiWordSynonyms.testPf: 25/25 repetitions, seed18624C0DE.TestMultiWordSynonyms: 6/6; neighboringTestExtendedDismaxParser.testPfPs: 1/1, seed18624BEEF. Both runs had no failures, errors or skips.check -x testpassed. The working tree stayed clean. A stale Gradle lock was cleared before the successful tidy run and before any tests ran. The root check used a normal clone at the same SHA for Antora.sort=score desc,id desc, document 10 won forbar foo, whiletropical cyclone footied and returned 13,12,11,10.bar foophrase, ignoringbf, and dropping thecyclone foophrase. The tests were unchanged, and all temporary production changes were reverted.Verification record.
Related work
I also reviewed the surrounding phrase-query code. Separate PRs are forthcoming for explicit phrase slop and phrases following nested queries (SOLR-12532 and SOLR-15611). I am also preparing the eDisMax empty-phrase cleanup from Ian Springer's work in #4652 (SOLR-18314), keeping it separate from the DisMax ranking change. Linux verification of these follow-ups is pending. I am investigating synonym-dependent
pf2/pf3ranking separately under SOLR-12260. This PR preserves current scoring behavior.Limits
The supplied Crave seed
B3B4534A1A4D09F4was replayed on the exact historical merge F, andtestPfpassed 1/1; it also passed 1/1 on F with only the H1 test file overlaid and on H1. The reported failure did not reproduce, and this replay does not establish that the test change fixes it. Replay ran on Linux6.18.38+/ OpenJDK21.0.12.1, versus the original Crave host’s Linux6.8.0-51-generic/ Adoptium21.0.10. Replay receipt. Only one test file changes; production behavior is unchanged.AI-generated description. Nick Shanin directed the work and takes responsibility for this contribution.