[Bug] score function return different result when run same query twice

[yiguolei]

Search before asking

• I had searched in the issues and found no similar issues.

Version

doris 4.1.2

What's Wrong?

score function return different result when run same query twice.
sql
-- 1. 建表
CREATE TABLE doris_test_db.test_score_nd (
id INT NOT NULL,
name VARCHAR(100),
tag VARCHAR(50)
) DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 3
PROPERTIES('replication_num'='1');

-- 2. 建倒排索引（关键步骤）
CREATE INDEX idx_name ON doris_test_db.test_score_nd(name) USING INVERTED;

-- 3. 插数据
INSERT INTO doris_test_db.test_score_nd VALUES
(0,'李鹏','vip'),(1,'李鹏','normal'),(2,'李鹏','new'),(3,'李鹏','active'),
(4,'李鹏','dormant'),(5,'李鹏','staff'),(6,'李鹏','manager'),(7,'李鹏','vip'),
(8,'李鹏','normal'),(9,'李鹏','new'),(10,'李鹏','active'),(11,'李鹏','dormant'),
(12,'李鹏','staff'),(13,'李鹏','manager'),(14,'李鹏','vip'),(15,'李鹏','normal'),
(16,'李鹏','new'),(17,'李鹏','active'),(18,'李鹏','dormant'),(19,'李鹏','staff'),
(20,'李鹏','manager'),(21,'李鹏','vip'),(22,'李鹏','normal'),(23,'李鹏','new'),
(24,'李鹏','active'),(25,'李鹏','dormant'),(26,'李鹏','staff'),(27,'李鹏','manager'),
(28,'李鹏','vip'),(29,'李鹏','normal'),(30,'李鹏','new'),(31,'李鹏','active'),
(32,'李鹏','dormant'),(33,'李鹏','staff'),(34,'李鹏','manager'),(35,'李鹏','vip'),
(36,'李鹏','normal'),(37,'李鹏','new'),(38,'李鹏','active'),(39,'李鹏','dormant'),
(40,'李鹏','staff'),(41,'李鹏','manager'),(42,'李鹏','vip'),(43,'李鹏','normal'),
(44,'李鹏','new'),(45,'李鹏','active'),(46,'李鹏','dormant'),(47,'李鹏','staff'),
(48,'李鹏','manager'),(49,'李鹏','vip');

-- 4. 验证索引已生效
SHOW INDEX FROM doris_test_db.test_score_nd;

-- 5. 复现非确定性排序（多跑几次看结果是否不同）
SELECT id, name, tag, score() AS relevance
FROM doris_test_db.test_score_nd
WHERE SEARCH('name:"李鹏"')
ORDER BY relevance DESC
LIMIT 10;

What You Expected?

Should return the same result.

How to Reproduce?

No response

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_cb135054c297
This content is generated by AI for reference only.

Initial code-level triage:

This looks like a real score() correctness bug, not only an unstable LIMIT tie issue. The screenshot shows one execution returning non-zero BM25 scores and the next execution returning 0 for all returned rows.

I checked the Doris 4.1.2 code path, where the public 4.1.2 tag points to the same commit as 4.1.2-rc01. The likely root cause is the interaction between score() materialization and the segment condition cache:

• enable_condition_cache is enabled by default and FE sets condition_cache_digest when it is enabled.
• BE disables condition cache for TopN filters, but not for ORDER BY score() / ScoreRuntime.
• On a condition-cache hit, SegmentIterator::_init_row_bitmap_by_condition_cache() filters _row_bitmap from the cached bitmap/block result.
• For SEARCH(...), the inverted-index expression can then be treated as already evaluated and removed from _common_expr_ctxs_push_down.
• Later, SegmentIterator::_prepare_score_column_materialization() still materializes score() from IndexQueryContext::collection_similarity.
• The condition cache only stores filter results, not BM25 scores. Therefore on a cache-hit path the per-query CollectionSimilarity score map can be empty, and CollectionSimilarity::get_topn_bm25_scores() / get_bm25_scores() falls back to 0.0F for rows not found in _bm25_scores.

This also explains why the first execution can return non-zero scores and a later execution of the same SQL can return zeros. The inverted-index query cache itself already avoids cache hits when similarity scoring is required, so the problematic cache here is the separate condition cache.

Suggested confirmation:

1. Re-run the query after SET enable_condition_cache = false;. If this diagnosis is correct, score() should stay non-zero across repeated executions.
2. Compare the runtime profile of the bad execution and check whether ConditionCacheSegmentHit is greater than 0.
3. Please also provide the exact build hash/tag and the output of SHOW VARIABLES LIKE 'enable_condition_cache';.

Suggested fix direction:

• Do not use condition cache for scans that need ScoreRuntime / score() materialization, or
• make the cache path force inverted-index scoring execution so collection_similarity is populated before score() is materialized.

A regression test should run the same SEARCH(...) ORDER BY score() DESC LIMIT ... query twice with condition cache enabled and assert that the second execution still returns non-zero scores. Since all rows in this repro contain the same searched term and should have equal BM25 scores, add a deterministic tie breaker such as ORDER BY relevance DESC, id ASC if the expected row order itself is asserted.