[airborne12]

What problem does this PR solve?

Issue Number: N/A

Related PR: #67363 (same fix on branch-4.1), #67327 (backported the suite to branch-4.1), #65821 (introduced the suite on master)

Problem Summary:

test_search_score_topn_predicates (added on master by #65821) runs in the shared concurrent P0 group. On branch-4.1 it fails intermittently on its very first query, right after CREATE TABLE + INSERT + sync, with:

errCode = 2, detailMessage = [INTERNAL_ERROR]SearchExpr should not be executed without inverted index

This was observed on branch-4.1 CI (2 failures out of 4 runs) and fixed there by #67363, which moves the case into the nonConcurrent group. master carries the identical suite grouping ("p0"), so it is exposed to the same intermittent failure when the case races other P0 cases. This PR applies the same one-line fix to master to keep it out of the concurrent group.

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[airborne12]

run buildall

[airborne12]

run nonConcurrent

[airborne12]

run nonConcurrent

[airborne12]

Status update on verification: the NonConcurrent pipeline has now failed three times in a row on this PR (builds 1036154, 1036404, 1036651) and in all three the run collapsed before reaching test_search_score_topn_predicates — the suite appears in neither the passed nor the failed list of any of them.

All three show the same environment signature rather than a test problem: FE IMAGE GENERATED FAIL (checkpoint failure) plus stop grace fail, with the run aborting after only 75-494 of the group's cases. The failures that are recorded are in unrelated suites — datatype_p0, ann_index_p0, table_stream_p0, row_binlog_p0, doc — none of which this one-line test-tag change touches.

I am not re-triggering further. What is verified so far: the suite passes locally with the tag applied, and the tag itself is the same grouping 41 other inverted_index_p0 cases already use. The final CI confirmation that it executes green inside the nonConcurrent group needs that pipeline to complete a run.

[airborne12]

/review

[eldenmoon]

LGTM

[github-actions]

No actionable findings in the complete diff at head 5d46ec6. The one-line change moves this existing suite to the framework's serial phase while retaining p0 membership.

Core invariants: production data visibility, version selection, delete bitmaps and memory ownership are unaffected; existing result comparisons and expected-error checks remain active.

Critical checkpoint conclusions:

• Goal and proof: comma-separated group parsing selects SINGLE; its one-thread executor serializes these bodies after NORMAL suite completion. This establishes scheduling behavior statically; elimination of the reported intermittent SearchExpr failure was not verified at runtime.
• Scope and reuse: minimal metadata edit using the established nonConcurrent mechanism; suite name, SQL and data path are retained.
• Concurrency and locks: NORMAL script futures wait for suite closure through a Phaser before SINGLE work starts. No shared variable or lock changes. Existing DOCKER/SINGLE overlap is framework behavior; no global isolation claim is made.
• Lifecycle and initialization: existing suite connection/output cleanup and Phaser deregistration remain intact; no new static initialization or ownership.
• Configuration: no production configuration item or dynamic setting added.
• Compatibility: no symbol, protocol or storage-format change.
• Parallel paths: checked score/cache and score/delete sibling tests; no corresponding edit was shown necessary.
• Conditions and errors: no new condition; the LIMIT+OFFSET overflow case retains its test/exception assertion.
• Coverage: twelve existing query checks retain equality, MATCH, range, LIMIT/OFFSET, multiple/nested/negated SEARCH and score-filter coverage, plus the overflow negative case.
• Results: all twelve qt tags match the unchanged golden blocks; each query explicitly orders the outer result by id. Output lookup uses the unchanged script path rather than group. No new or modified expected results.
• Observability: existing suite/group and failure logging is adequate for this registration change.
• Transactions and persistence: no transaction, EditLog, persistence or failover logic changed.
• Writes and failure handling: existing DROP-before-CREATE, INSERT and SYNC setup is preserved; no write implementation changed.
• FE/BE variables: no new field or session variable; existing SET statements are unchanged.
• Performance: intentionally adds this small suite to serial work; no new loops, repeated scans or production hot-path cost.
• Other issues and selection: checked repository serial-job configuration and triggers retain the suite. Concurrent-only invocations using runNonConcurrent=false intentionally skip it. No verified duplicate-execution, output-lookup or selection defect was found.

Existing review context contains no inline findings; existing_blocking_comment_ids is empty. No additional user focus was supplied. Both the full-scope reviewer and separate scheduling-risk reviewer completed missed-issue rechecks; no unresolved in-scope candidate remains. Review converged after 2 rounds.

Static-only review: no builds or tests were run. Runtime stability, live CI results and external TeamCity job arguments were not verified. These limits do not establish whether serial execution cures the reported flake.

Review converged after 2 round(s).