[fix](arrow-flight) Do not take the point-query short circuit on an Arrow Flight connection

[morningman]

What problem does this PR solve?

Issue Number: close #67368

Related PR: #67381 (sibling fix in the same tracking series), #62259

Problem Summary:

A UNIQUE KEY point query that qualifies for the short-circuit path returned no Flight endpoint over Arrow Flight SQL. The client failed with

fetch arrow flight schema failed, no FlightSqlEndpointsLocations

and the row was silently dropped. The identical query with SET_VAR(enable_short_circuit_query=false) returned it on the same connection.

Root cause — the short circuit produces no Arrow result at either end, and nothing prevented an Arrow Flight connection from planning one:

• It executes on PointQueryExecutor, not a Coordinator, and Coordinator/NereidsCoordinator are the only places that register a FlightSqlEndpointsLocation. StmtExecutor.executeAndSendResult then returns early through its Arrow Flight branch with nothing registered and without ever calling getNext(), so GetFlightInfo found an empty endpoint list.
• The BE cannot be pointed at either. tablet_fetch_data serializes with VMysqlResultWriter into PTabletKeyLookupResponse.row_batch and runs no fragment, so the ArrowFlightResultBlockBuffer that fetch_arrow_flight_schema looks up by finst id never exists.

LogicalResultSinkToShortCircuitPointQuery did not look at the connect type, and enable_short_circuit_query defaults to true, so every ADBC / Arrow Flight JDBC point query on a MoW + light-schema-change + store_row_column table hit this. Prepared statements go through the same executeQueryStatement and failed identically.

Fix — keep Arrow Flight SQL on the normal execution path.

This has to be decided at plan time rather than when picking the executor: OlapScanNode.computeTabletInfo and several rewrite/property rules (ChildOutputPropertyDeriver, ShuffleKeyPruner, NestedColumnPruning, PruneOlapScanPartition) read StatementContext.isShortCircuitQuery() while the plan is being built, so flipping the flag later would run a coordinator over a plan shaped for a different execution mode. MySQL connections keep the short circuit unchanged.

Returning the point-query result from the FE instead was considered and rejected for now: FlightSqlChannel.addResult builds varchar vectors only, so every column would come back as Utf8, inconsistent with the normal Flight path. Full support (Arrow serialization in the BE lookup RPC plus a result buffer to hand out an endpoint) is a larger change and out of scope here.

Also refreshes a now-stale comment in StmtExecutor that said point queries reach the Arrow Flight deferral gate.

Release note

Fix Arrow Flight SQL returning no endpoint (no FlightSqlEndpointsLocations) for a point query that hits the short-circuit path.

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

regression-test/suites/arrow_flight_sql_p0/test_point_query_over_arrow_flight.groovy uses the table from the issue and holds both a MySQL and an Arrow Flight connection. It asserts the MySQL explain still contains SHORT-CIRCUIT (so a table that stopped qualifying fails loudly instead of making the rest pass for the wrong reason), that the Flight explain does not, that both protocols return the same row, and that the numeric columns stay numeric over Flight.

ShortCircuitPointQueryTest#testArrowFlightSqlConnectionDoesNotUseShortCircuit covers the rule itself and re-asserts that the same statement still short circuits on a MySQL connection.

Verified on a local single-FE + single-BE cluster, all three runs on the same cluster:

Run	FE	Result
1	with the fix	All suites success, Test 1 suites, failed 0
2	guard temporarily disabled	failed — the point query must not short circuit on an arrow flight connection
3	fix restored	All suites success, Test 1 suites, failed 0

Run 2 is the negative control; the explain it captured is the bug itself, with a Flight result sink and the short circuit in one plan:

  VRESULT SINK
     ARROW_FLIGHT_PROTOCOL
  0:VOlapScanNode(28)
     ...
     SHORT-CIRCUIT

FE UT: Tests run: 8, Failures: 0, Errors: 0 for ShortCircuitPointQueryTest.

• Behavior changed:

  • No.
  • Yes. A point query over Arrow Flight SQL is now planned on the normal execution path instead of the short circuit, so it returns its row instead of failing. It gives up the point-query latency benefit on that protocol; MySQL connections are unaffected.

• Does this need documentation?

  • No.
  • Yes.

🤖 Generated with Claude Code

https://claude.ai/code/session_017omcvWDsxEc9AyU83aBZ2g

[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?

[morningman]

run buildall

[morningman]

/review

[github-actions]

Review result: request changes for one regression-test convention issue.

Critical checkpoints:

• Goal and correctness: the planner-time Arrow Flight fence addresses the no-endpoint failure at the authoritative short-circuit marker, before partition pruning and physical-property consumers. Normal, EXPLAIN, Flight prepared-handle, SQL prepared, retry, matching-row, and empty-row paths were traced; no stale marker or alternate point-executor path remains for an Arrow connection.
• Scope and clarity: the production change is focused to one enum gate plus a clarifying StmtExecutor comment. Error handling is not suppressed; Arrow is routed to the established coordinator path.
• Concurrency and lifecycle: no new locks or shared mutable lifecycle are introduced. The stable volatile connection type is read during synchronous planning, and the existing deferred coordinator/result-buffer lifecycle spans GetFlightInfo and DoGet. Endpoint IDs match BE buffer IDs in both normal and parallel result-sink modes.
• Configuration and compatibility: no config, persistence, transaction/write behavior, FE-BE field, storage format, or symbol compatibility changes are introduced. MySQL retains the short circuit; Arrow intentionally pays normal-plan cost until the point executor can produce Arrow results.
• Tests: the FE unit test controls the marker and ordinary empty plan; the end-to-end regression controls MySQL eligibility, Flight planning, actual matching and missing results, type preservation, the disable hint, and a non-point query. I inspected but did not execute tests because this review environment explicitly prohibits builds/tests.
• Observability: the existing endpoint/schema errors and coordinator logging are adequate for this narrow routing change; no new metric is required.
• User focus and completion: no additional user focus was provided. Two review rounds converged with every candidate accepted, deduplicated, or dismissed with code evidence; the single accepted issue is inline below.

Separately, the current PR title check is failing because the workflow regex does not accept the arrow-flight scope. arrow_flight or arrow flight matches that checker. Compile, FE UT, and performance checks were still pending when this review was submitted.

dismiss

[hello-stephen]

FE UT Coverage Report

Increment line coverage 50.00% (2/4) 🎉
Increment coverage report
Complete coverage report

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 6.25% (4/64) 🎉
Increment coverage report
Complete coverage report