Uh oh!
There was an error while loading. Please reload this page.
fix(ci): reconcile review-state labels against latest check run per name - #270
Conversation
1 issue outstanding; 2 checks still running. Action required. See task
|
| role: "assistant", | ||
| content: assistantContent, | ||
| } satisfies Anthropic.Messages.MessageParam) | ||
| ...(shouldReplayReasoningContent ? { reasoning_content: preservedReasoningContent } : {}), |
There was a problem hiding this comment.
prepareApiConversationMessage() only stores top-level reasoning_content for apiProtocol === "openai" (src/core/task/apiConversationHistory.ts). Anthropic-style thinking providers in this repo still set info.preserveReasoning (for example MiniMax and the Bedrock Kimi/MiniMax models) but persist their reasoning as embedded blocks, so this branch now strips the reasoning those continuations need.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
eed0aaf to
6184c33Compare
edelauna
left a comment
There was a problem hiding this comment.
Squatting this old PR - to fix a small bug in how labels are tagged
Uh oh!
There was an error while loading. Please reload this page.
Related GitHub Issue
Fixes: #884
Description
The
Label PR review stateworkflow evaluates a PR's CI by scanning every check run thatchecks.listForRefreturns for the head commit, then taking.some()across all of them. A single stale failed check run — one later superseded by a green run of the same check — keepsciFailed = trueforever. As a resultawaiting-author/awaiting-reviewlabels get stripped on the next hourly run and never come back, even though the PR UI and branch protection correctly show CI as green.Observed on #509 (and #476): the head commit carries an old failed
e2e-mockrun alongside later greene2e-mockruns, so the workflow logsPR #509: CI failed — stripping state labelson every run and the review-state label never returns.Change
Reduce to the latest check run per name before evaluating
ciPending/ciFailed, so the workflow sees the same current state that branch protection and the PR UI use:The latest run is selected by
run.id(GitHub-assigned, monotonically increasing, never null) rather thanstarted_at, because a freshly re-queued run can havestarted_at: nulland would lose a string comparison against an older completed run's timestamp — reintroducing a narrowed version of the same bug.After this change, the next
schedule/workflow_dispatchrun re-applies the correct review-state label to affected PRs (e.g.awaiting-authoron #509).Test Procedure
e2e-mockcheck runs on fix: use VS Code default shell for command execution instead of /bin/sh #509's head commit (50b9df8):run.idis monotonic with recency (79875030339failure →79880428333success →82684589430success), confirming the dedup resolves to the latest green run.PR #509: CI failed — stripping state labels.Pre-Submission Checklist
Screenshots / Videos
Not applicable — internal CI-workflow logic change.
Documentation Updates
Additional Notes
The workflow's own inline comments already note that
schedule/workflow_dispatchruns reconcile fork PRs normally; this change is orthogonal to that fork-handling path. PRs that were stuck unlabeled due to stale check runs (e.g. #509, #476) will recover automatically once this merges and the next hourly run fires.Get in Touch
Roomote (task
0mzxfggobdyy)