chore(ci): bump umm-actually to v0.4.5 - #31
Conversation
aliasunder
changed the title
![umm-actually[bot]](https://avatars.githubusercontent.com/in/4233716?s=60&v=4){kind=small}
|
umm-actually re-reviewed at 2 new finding(s) posted (5 tracked finding(s) across all runs). Review phase The review deadline expired; results from completed phases are shown. umm-actually · deepseek/deepseek-v4-flash-0731 |
|
Mirror issue.pull_request in the concurrency noop condition
The concurrency noop condition omits the Failure scenario: While a review of PR #42 is running, the owner writes '@umm review' on issue #42 (a regular issue, not a PR). The new run gets the non-noop group Suggested fixAdd `github.event.issue.pull_request` to the issue_comment leg of the noop condition, mirroring the job guard:
```yaml
((github.event_name == 'issue_comment' && !(github.event.issue.pull_request && github.event.comment.user.login == github.repository_owner && startsWith(github.event.comment.body, '@umm review'))) || ...)
```umm-actually · minimax/minimax-m3, deepseek/deepseek-v4-flash-0731 |
|
False positive for issue comment #5707575345 — GitHub uses one repository-wide number for an issue or pull request, so a regular issue #42 and PR #42 cannot coexist. An owner trigger on a regular issue therefore cannot share a concurrency group with a same-numbered PR. 🔍 ship-check · pr-monitor · gpt-5.6-sol |
| # Shared cap across review work. Empty = 1500. Use 1500 or less | ||
| # to leave publication headroom before the 30-minute job timeout. | ||
| review_timeout_seconds: ${{ vars.UMM_REVIEW_TIMEOUT_SECONDS }} |
There was a problem hiding this comment.
Warn that a request timeout consumes most of the review budget
Low severity · ci · medium confidence
The new review_timeout_seconds comment bounds the shared review budget against the job timeout only, never against the sibling request_timeout_seconds knob. The wired defaults (900s per attempt, 1500s shared) mean a single timed-out primary attempt consumes 60% of the review budget, so the fallback model receives less than its own per-attempt allowance and a review that needs both attempts is cut off by the shared cap even though neither request exceeded its own timeout — nothing in the workflow warns of this interaction, and the request-timeout comment still presents the retry/fallback ladder as the recovery path.
Failure scenario: A maintainer raises UMM_REQUEST_TIMEOUT_SECONDS to 1400s to accommodate a slow model while UMM_REVIEW_TIMEOUT_SECONDS stays at the 1500s default. The primary request times out at 1400s, consuming nearly all of the shared review budget; the fallback attempt is killed within seconds even though its own per-attempt timeout is 1400s, and the review run posts no findings — with no comment anywhere in the workflow explaining why.
Suggested fix
Extend the review_timeout_seconds comment with the budget relationship, e.g. append: "Keep request_timeout_seconds well below this value — a timed-out attempt consumes the shared budget and can starve the fallback model."umm-actually · deepseek/deepseek-v4-flash-0731
|
Include the owner issue-comment path in the noop concurrency group
The concurrency noop condition omits the Failure scenario: An owner comments Suggested fixMirror the job-if guard in the concurrency group expression, or append '-noop-' whenever `github.event_name == 'issue_comment'` and the issue is not a pull request:
```yaml
((github.event_name == 'pull_request' && !(github.event.pull_request.user.login == github.repository_owner && github.event.pull_request.head.repo.full_name == github.repository)) ||
(github.event_name == 'issue_comment' && !(github.event.issue.pull_request && github.event.comment.user.login == github.repository_owner && startsWith(github.event.comment.body, '@umm review'))) ||
(github.event_name == 'workflow_dispatch' && true)) && format('-noop-{0}', github.run_id) || ''
```umm-actually · deepseek/deepseek-v4-flash-0731 |
1 participant
Summary
Validation