You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Decide How Long wait Looks Before Calling a Copilot Request Unrecorded #2024
Handoff: #1977, track auto-1904, for #1904. Branch feature/auto-1904 is pushed at eb66c38f. No pull request is open yet, so this decision blocks the feature -> develop pull request that branch would open.
Question
How long should pr_review.py wait look before it calls a Copilot review request unrecorded and skips the poll with exit 48?
Following the answer to #1978, this round made the requested fix, then ran three more local strict review passes with two edit rounds between them. That is the point where local-strict-review "Disposing of Findings" stops editing and hands what remains to the maintainer. Counts across the three passes: 8 findings, 6 introduced fixed, 2 introduced open, 0 pre-existing, 0 style.
Both open findings have the same root. Any lag between GitHub accepting the request and the request showing up is now read as "nothing was recorded," because the wait decides with no pause:
The last check before exit 48 is reviewer_requested over the digest read (Q_FULL). That read has no review-request events, and it skips request_recorded's drifted-login guard. Suppose the event lands only at that read, after Copilot has already left the pending set. The wait still exits 48, and it prints "no review-request event" although it never looked for one.
The mutation's answer, the readback, and the digest read run back to back with nothing waiting between them, so they only cover a lag of a few round trips. Before this branch, the poll's first 15-second delay absorbed any recording lag. Now a request that becomes visible within those 15 seconds exits 48 and routes to the maintainer as an allowance problem.
Every edit round so far has closed one window and left the next one open. So the choice is between designs, not between wordings.
Options
Recommended: decide 48 after one poll interval, with one predicate. When the answer reads unrecorded, the wait still sleeps its first delay. It then reads REQUEST_STATE and judges it with request_recorded, and exits 48 only if that read is still unrecorded and the digest read does not show the reviewer pending. It costs 15 seconds on a genuine exhausted allowance, which is still nowhere near the full timeout A Copilot Review Request That Adds No Timeline Event Reads as Patience #1904 complained about, and it removes both findings' windows. The lane resumes with one more edit round and one more local pass, then the feature -> develop pull request, driven as usual.
Keep polling, and report the state only at the timeout. An unrecorded answer prints a note, the poll runs its full --timeout, and the exit is 48 instead of 30 only if the request is still unrecorded when the timeout ends. There is no race window left to argue about, but this gives up the promptness A Copilot Review Request That Adds No Timeline Event Reads as Patience #1904 asked for.
Open the pull request as it stands and file both findings as a follow-up issue. The detection works whenever GitHub records a request before the digest read returns. The cost is merging a known false-48 window of unmeasured size to develop.
Answered by the maintainer: option 1, decide 48 after one poll interval with one predicate. Sleep the first delay, re-read REQUEST_STATE and judge it with request_recorded, and exit 48 only if still unrecorded and the digest does not show the reviewer pending.
Handoff: #1977, track
auto-1904, for #1904. Branchfeature/auto-1904is pushed ateb66c38f. No pull request is open yet, so this decision blocks the feature -> develop pull request that branch would open.Question
How long should
pr_review.py waitlook before it calls a Copilot review request unrecorded and skips the poll with exit 48?Following the answer to #1978, this round made the requested fix, then ran three more local strict review passes with two edit rounds between them. That is the point where
local-strict-review"Disposing of Findings" stops editing and hands what remains to the maintainer. Counts across the three passes: 8 findings, 6introducedfixed, 2introducedopen, 0pre-existing, 0style.Both open findings have the same root. Any lag between GitHub accepting the request and the request showing up is now read as "nothing was recorded," because the wait decides with no pause:
reviewer_requestedover the digest read (Q_FULL). That read has no review-request events, and it skipsrequest_recorded's drifted-login guard. Suppose the event lands only at that read, after Copilot has already left the pending set. The wait still exits 48, and it prints "no review-request event" although it never looked for one.Every edit round so far has closed one window and left the next one open. So the choice is between designs, not between wordings.
Options
REQUEST_STATEand judges it withrequest_recorded, and exits 48 only if that read is still unrecorded and the digest read does not show the reviewer pending. It costs 15 seconds on a genuine exhausted allowance, which is still nowhere near the full timeout A Copilot Review Request That Adds No Timeline Event Reads as Patience #1904 complained about, and it removes both findings' windows. The lane resumes with one more edit round and one more local pass, then the feature -> develop pull request, driven as usual.--timeout, and the exit is 48 instead of 30 only if the request is still unrecorded when the timeout ends. There is no race window left to argue about, but this gives up the promptness A Copilot Review Request That Adds No Timeline Event Reads as Patience #1904 asked for.