github-actions[bot] commented on code in PR #65178:
URL: https://github.com/apache/doris/pull/65178#discussion_r3564639817
##########
.github/workflows/code-review-runner.yml:
##########
@@ -294,38 +339,47 @@ jobs:
- Raw inline review comments JSON:
PLACEHOLDER_CONTEXT_DIR/pr_review_comments.json
- User review focus: PLACEHOLDER_CONTEXT_DIR/review_focus.txt
- PR changed files: PLACEHOLDER_CONTEXT_DIR/pr_changed_files.txt
+ - Authoritative aggregate PR diff: PLACEHOLDER_CONTEXT_DIR/pr.diff
- Required AGENTS.md files:
PLACEHOLDER_CONTEXT_DIR/required_agents.txt
- Shared subagent review ledger:
PLACEHOLDER_CONTEXT_DIR/subagent_review_findings.md
+ PR diff and path-reading (for all subagents and the main agent):
+ - PLACEHOLDER_CONTEXT_DIR/pr.diff is the authoritative aggregate
diff for the whole PR, and PLACEHOLDER_CONTEXT_DIR/pr_changed_files.txt is the
authoritative changed-path list. Do not obtain the PR diff or changed-path list
through other means.
+ - Before reading any file whose exact path is not already confirmed
by PLACEHOLDER_CONTEXT_DIR/pr_changed_files.txt,
PLACEHOLDER_CONTEXT_DIR/pr.diff, or a previous successful command output, you
MUST first run `rg --files` to confirm the actual path of the target file.
+
Before reviewing any code, you MUST read and follow the code review
skill in this repository. During review, you must strictly follow those
instructions.
The active review goal's progress tracking MUST include, and must
stay current throughout the review:
- - Read the review prompt, code-review skill, required AGENTS.md
files, existing review threads, user focus, changed-file list, and the shared
subagent review ledger.
- - Spawn the required focused subagents and assign each subagent a
dedicated section in the shared ledger before it reviews.
- - Require every subagent to append only to its assigned ledger
section, while reading the whole ledger to avoid duplicate candidates.
- - Read the shared ledger after every subagent result, then
independently verify, deduplicate, accept, or dismiss every candidate in the
main merged section.
- - Run at least one final convergence round where every live subagent
reviews the current ledger and proposed final comment set.
- - Continue reviewing if any subagent reports a new valuable
candidate during convergence; repeat verification and convergence until every
subagent says `NO_NEW_VALUABLE_FINDINGS` for the same current ledger/comment
set.
- - Submit the final GitHub review and verify that all accepted
comments landed before marking the goal complete.
- The active review goal MUST remain incomplete until every suspicious
point found during review has a clear conclusion: submitted as an inline issue,
dismissed as already covered by existing review context, or dismissed with
concrete code evidence explaining why it is not a bug.
- You MUST use the available subagent or multi-agent spawn tool for
this review; do not merely simulate subagent output in your own text. If tool
discovery is needed, search for the subagent/multi-agent tool first. Spawn at
least two subagents before final submission:
- - one subagent assigned to the `optimizer-rewrite` ledger section
and focused on optimizer/rewrite correctness, semantic equivalence, and
parallel join/aggregate paths.
- - one subagent assigned to the `tests-session-config` ledger section
and focused on regression tests, expected outputs, session/config propagation,
compatibility, and basic CI/style failures.
- The shared subagent review ledger is
PLACEHOLDER_CONTEXT_DIR/subagent_review_findings.md. Before spawning any
subagent, the main agent MUST read this ledger. Every subagent prompt MUST
include this ledger path and the exact ledger section assigned to that
subagent. Subagents must read the whole ledger before reviewing, avoid
duplicating existing candidates, and append their findings only under their
assigned subagent section. They must not rewrite the whole ledger, edit another
subagent section, edit the main merged sections, edit repository source files,
or submit GitHub comments.
- Each subagent must record candidate findings in its own ledger
section with stable IDs, path/line, claim, evidence, duplicate relationship if
any, and recommendation. If a candidate overlaps an existing ledger item, the
subagent should add a duplicate note in its own section that references the
existing candidate ID instead of modifying the existing candidate. This
section-owned append-only rule is mandatory to avoid concurrent patch conflicts.
- The main agent must read the shared ledger after each subagent
result, merge duplicate candidates into the main merged section, update
candidate statuses, and keep a proposed final comment set in the main-owned
ledger sections. Statuses must distinguish at least: proposed_by_subagent,
accepted_for_inline_comment, dismissed_with_evidence,
duplicate_of_existing_thread, duplicate_of_candidate, and needs_more_evidence.
- Before final submission, the main agent MUST send the current ledger
and proposed final comment set to every live subagent and require a convergence
response. A subagent may either append a new valuable candidate under its
assigned section or reply exactly `NO_NEW_VALUABLE_FINDINGS` for the current
ledger/comment set. The main agent MUST NOT complete the goal, final summary,
or GitHub review until every live subagent has returned
`NO_NEW_VALUABLE_FINDINGS` in the same convergence round after the last
accepted or dismissed candidate update.
- Subagents must only report candidate findings with evidence. The
main agent must read their results and the shared ledger, independently verify
or dismiss every candidate with concrete code evidence, deduplicate against
existing review threads, and submit the final GitHub review itself. The final
summary must include a short "Subagent conclusions" section describing which
subagent candidates became inline comments, which were dismissed, which
duplicates were merged, and which convergence round ended with all subagents
reporting `NO_NEW_VALUABLE_FINDINGS`.
- If and only if the runtime exposes no subagent or multi-agent tool
after explicit discovery, state that limitation in the final summary and
continue the review manually.
- You MUST NOT stop after finding the first blocking issue. Keep
reviewing changed files, related control flow, tests, and parallel/special-case
paths until all plausible correctness, lifecycle, configuration, compatibility,
performance, and coverage bugs have been investigated and every bug you can
substantiate has been reported.
- Before submitting the final review, do one explicit final sweep over
the changed-file list and your unresolved candidate list. Only finish when
there are no unresolved suspicious points and all possible substantiated bugs
have been pointed out in the GitHub review.
+ 1. Read the review prompt, code-review skill, required AGENTS.md
files, existing review threads, user focus, changed-file list, and the shared
subagent review ledger.
+ 2. Perform a main-agent initial risk scan before spawning review
subagents. You must thoroughly read all the changes in this PR and understand
all the involved mechanisms, pointing out: if there is a problem with this PR,
where is the problem most likely to be? Or are there any points you suspect to
be risky? write the result under `## Main Initial Risk Scan` in the shared
ledger.
+ 3. Based on the requirements of the code-review skill regarding the
coverage points of the review spawn 1-3 subagents (depends on the complexity of
the PR), each focusing on certain aspects. The sum of their focus points must
fully cover the entire content of PR, as well as the points required in skill
and any additional review points you consider necessary. They must complete the
review of their own aspects and identify all possible issues before they can
finish their work. You need assign each subagent a dedicated section in the
shared ledger.
+ 4. If the main initial risk scan identifies one or more suspicious
mechanisms, spawn additional risk-focused subagent(s), separate from the normal
complete-review subagents, to specially investigate those specific mechanisms
and their upstream/downstream interactions.
Review Comment:
This creates two incompatible exit gates for the review. The prompt first
says the final GitHub review can only be submitted after every subagent returns
`NO_NEW_VALUABLE_FINDINGS`, but this step also tells the agent to submit after
three rounds even if convergence was not reached. Since the workflow success
check only verifies that some review was submitted for the current head SHA, an
explicitly incomplete review can still be treated as a successful automated
review. Please make the three-round cap a non-success path, or remove the hard
convergence requirement; as written, this can green-light incomplete reviews.
##########
.github/workflows/code-review-runner.yml:
##########
@@ -390,18 +455,6 @@ jobs:
Duplicate relationship:
Recommendation:
- ## Subagent Candidate Sections
-
- ### optimizer-rewrite
-
- Subagent assignment: optimizer/rewrite correctness, semantic
equivalence, and parallel join/aggregate paths.
- Append only below this line and above the next subagent heading.
-
- ### tests-session-config
Review Comment:
The ledger template still says subagents may append only under `Subagent
Candidate Sections`, but this PR removes the `## Subagent Candidate Sections`
block and the default subagent headings before `## Main Merged Findings`. A
goal-mode review that follows the generated prompt now has no pre-created
append target for its spawned subagents, even though the prompt requires each
subagent to append only to its assigned ledger section. That leaves the main
agent to invent the ledger structure at runtime and can cause subagents to fail
or append into main-owned sections. Please keep the explicit subagent
container/headings in the generated ledger, or add an explicit main-agent step
that creates them before any subagent is spawned.
--
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]
