Baymine opened a new issue, #66282:
URL: https://github.com/apache/doris/issues/66282

   ### Search before asking
   
   - [X] I had searched in the 
[issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no 
similar issues.
   
   ### Version
   
   master / branch-4.0
   
   ### What's Wrong?
   
   A fragment's pipeline count is built at runtime per backend (`add_pipeline` 
reacts to data distribution and local-exchange injection), so backends of one 
fragment can legitimately report **different** pipeline counts (e.g. most 
backends at 3 pipelines and one at 8).
   
   `ExecutionProfile.getMultiBeProfile()` computes `pipelineSize` as the 
**max** pipeline count across backends, then indexes **every** backend at each 
position:
   
   ```java
   for (int pipelineIdx = 0; pipelineIdx < pipelineSize; pipelineIdx++) {
       for (List<RuntimeProfile> profileSingleBE : multiPipeline.values()) {
           RuntimeProfile pipeline = profileSingleBE.get(pipelineIdx); // <-- 
OOB
           ...
   ```
   
   Backends with fewer pipelines than the max throw `IndexOutOfBoundsException` 
(`Index 1 out of bounds for length 1`), which aborts the merge and loses the 
entire merged profile for the query.
   
   ### What You Expected?
   
   Backends that report fewer pipelines than the fragment max should simply be 
skipped at the higher indices, and the merged profile should be produced 
without error.
   
   ### How to Reproduce?
   
   Run a query whose fragment ends up with different pipeline counts on 
different backends (data-distribution / local-exchange driven), then inspect 
the merged query profile — it fails to generate.
   
   ### Anything Else?
   
   Fix: add a bounds check so a backend with no profile at `pipelineIdx` is 
skipped instead of indexed out of bounds. PR incoming.
   
   ### Are you willing to submit PR?
   
   - [X] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [X] I agree to follow this project's [Code of 
Conduct](https://www.apache.org/foundation/policies/conduct)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to