github-actions[bot] commented on code in PR #66317:
URL: https://github.com/apache/doris/pull/66317#discussion_r3688897022
##########
.github/workflows/code-review-runner.yml:
##########
@@ -607,7 +607,7 @@ jobs:
- name: Run automated code review
id: review
- timeout-minutes: 60
+ timeout-minutes: 115
Review Comment:
This extends the maximum interval from an early token refresh until auth
write-back from roughly 72-75 to 132-135 minutes, but pool selection is
still with replacement and has no lease. Run A can refresh R0 locally while
run B downloads the still-remote R0; after the server's hour-scale reuse
window, B can no longer refresh it
(https://github.com/openai/codex/issues/10332). Its structurally valid stale
file can also pass the `always()` cleanup checks. Please hold an exclusive
lease for each auth object through download/refresh/upload to prevent the
overlapping refresh failure, and make upload conditional/version-fenced to
prevent stale rollback.
##########
.github/workflows/code-review-runner.yml:
##########
@@ -763,7 +763,7 @@ jobs:
- name: Record review I/O to Litefuse
if: ${{ always() }}
continue-on-error: true
- timeout-minutes: 5
+ timeout-minutes: 10
Review Comment:
This doubles a demonstrated post-timeout write window. In run 30605955928
the review step timed out and failure was published at 06:09:44-46, but
review 4825945365 and comments 3688450282/3688450289 still landed at
06:14:31 while this step kept the job alive until 06:14:59. Because the
job-scoped token remains valid until job completion, a surviving Codex
descendant can keep mutating the PR after its verifier has ended. Make the
review timeout cancel and await all descendants (or revoke/fence a
run-scoped submission credential) before entering telemetry; increasing a
telemetry timeout must not extend review authority.
##########
.github/workflows/code-review-runner.yml:
##########
@@ -607,7 +607,7 @@ jobs:
- name: Run automated code review
id: review
- timeout-minutes: 60
+ timeout-minutes: 115
Review Comment:
The only live head/base fence runs before context generation. During this
115-minute step the PR can move from H1 to H2, while both submission
branches remain unfenced: the REST payload omits `commit_id` (so GitHub
defaults to current H2) and `gh pr review` cannot bind H1. The later query
only looks for some H1 review and never refetches the PR, so it can also
accept an obsolete H1 review after H2 exists. Refetch and require the live
base/head immediately before either submission, bind REST reviews to
`HEAD_SHA`, and independently recheck live refs after Codex returns.
##########
.github/workflows/code-review-runner.yml:
##########
@@ -607,7 +607,7 @@ jobs:
- name: Run automated code review
id: review
- timeout-minutes: 60
+ timeout-minutes: 115
Review Comment:
This longer overlap window has no per-PR/head run ownership. Verification
accepts any review after `review_started_at` with the same head, so a run
that submits nothing can be marked successful by another run's review
(including one with different focus). The same overlap lets slow run A post
`pending` after faster run B has posted `success`; the latest shared status
then wins. Serialize/cancel superseded runs per PR/head, or make both review
verification and final status publication run-owned/version-aware (capture
the created review ID and prevent an older run from downgrading a newer
result).
--
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]
