Issue Number: #55756

[sgy861]

What problem does this PR solve?

Issue Number: #55756

Related PR: N/A

Problem Summary:

In Cloud mode, SHOW PROC '/colocation_group/<groupId>' returns empty results even when the colocation group is stable and has valid bucket placement.

In non-cloud mode, this statement correctly shows the bucket-to-backend distribution of a colocation group. However, in Cloud mode, the proc lookup fails to resolve colocated backend IDs, resulting in no rows being returned.

This PR fixes the proc lookup logic to correctly resolve colocated backend information in Cloud mode by leveraging the cloud replica placement logic (e.g. CloudReplica#getColocatedBeId). After this fix, SHOW PROC '/colocation_group/<groupId>' behaves consistently between cloud and non-cloud environments.

---

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

Manual test steps

1. Start a Cloud-mode Doris cluster with at least one available BE.

2. Create two colocated tables with identical distribution and bucket settings:

   CREATE TABLE t1 (...) PROPERTIES ("colocate_with"="cg_test", "replication_num"="1");
   CREATE TABLE t2 (...) PROPERTIES ("colocate_with"="cg_test", "replication_num"="1");

3. Verify the colocate group exists:

   SHOW PROC '/colocation_group';

4. Query the colocate group distribution:

   SHOW PROC '/colocation_group/<groupId>';

5. Confirm that bucket-to-backend mapping is returned and not empty.

---

• Behavior changed:

  • No.
  • Yes.

This change only fixes missing output in Cloud mode for an existing statement. No user-facing behavior is changed beyond correcting incorrect empty results.

---

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

[sgy861]

What problem was fixed This PR fixes SHOW PROC '/colocation_group/{dbId}.{groupId}' in Cloud mode. Previously, ColocationGroupProcDir.lookup();always called ColocateTableIndex.getBackendsPerBucketSeq(groupId) to build backend sequences. In Cloud mode, this backend-sequence lookup is not applicable and could fail or return unusable results for the proc output. How it was fixed The fix adds Cloud-mode-aware logic to ColocationGroupProcDir.lookup(): Non-cloud mode: Preserve the existing behavior by calling getBackendsPerBucketSeq(groupId) and returning ColocationGroupBackendSeqsProcNode based on the computed backend sequences. Cloud mode: Validate the group exists by retrieving ColocateGroupSchema and throwing an AnalysisException if the group is missing. Validate the group contains at least one table (used to construct a representative CloudReplica) and throw an AnalysisException if empty. Construct per-bucket backend sequences by creating a CloudReplica for each bucket and calling replica.getBackendId() to resolve the backend mapping. Any ComputeGroupException ;is converted to an AnalysisException. Populate a Map<Tag, List<List<Long>>>using Tag.DEFAULT_BACKEND_TAG and return ColocationGroupBackendSeqsProcNode. This ensures proc output remains meaningful and functional in Cloud mode while keeping the original behavior unchanged for non-cloud deployments. Behavior changes Previous behavior: SHOW PROC '/colocation_group/{dbId}.{groupId} ' always relied on ColocateTableIndex.getBackendsPerBucketSeq(groupId), regardless of deployment mode. In Cloud mode, this could fail or produce invalid/unusable backend sequences. Current behavior: In non-cloud mode, behavior is unchanged. In Cloud mode, backend sequences are derived by resolving per-bucket backend IDs via CloudReplica.getBackendId(), and the proc now reports a valid backend sequence under DEFAULT_BACKEND_TAG. Rationale: Cloud mode requires backend resolution through cloud-specific mapping logic rather than the classic colocate backend sequence computation. Possible impact: The change affects only the FE-side proc implementation for colocation group backend sequences in Cloud mode. Error handling is stricter in Cloud mode: missing group or empty group now results in clear AnalysisException messages. New features N/A Refactoring N/A Optimization N/A Tests Manual verification: Verified SHOW PROC '/colocation_group still works as before. Verified SHOW PROC '/colocation_group/{dbId}.{groupId}' returns backend sequences correctly in Cloud mode, and produces appropriate errors for: non-existent group (Group does not exist) group with no tables (No table in colocate group) compute group resolution failures (propagated as AnalysisException with the underlying message). 原始邮件 发件人：Dongyang Li ***@***.***&gt; 发件时间：2025年12月25日 11:53 收件人：apache/doris ***@***.***&gt; 抄送：sgy861 ***@***.***&gt;, Author ***@***.***&gt; 主题：Re: [apache/doris] Issue Number: #55756 (PR #59350) hello-stephen left a comment (apache/doris#59350) 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: What problem was fixed (it's best to include specific error reporting information). How it was fixed. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be. What features were added. Why was this function added? Which code was refactored and why was this part of the code refactored? Which functions were optimized and what is the difference before and after the optimization? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.