Skip to content

chore(ci): bump umm-actually to v0.4.5 #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
aliasunder merged 4 commits into from
Sep 17, 2026
Merged

chore(ci): bump umm-actually to v0.4.5 #31

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
8d8eca6
chore: bump umm-actually to v0.4.5
aliasunder Sep 17, 2026
3b12700
docs(ci): clarify review timeout ceiling
aliasunder Sep 17, 2026
e1dc5bd
docs(ci): clarify workflow defaults
aliasunder Sep 17, 2026
9dc6fbc
docs(ci): tighten review timeout guidance
aliasunder Sep 17, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions .github/workflows/umm_review.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,11 +85,11 @@ jobs:
permission-checks: write

# Every optional input is overridable via a repo variable (Settings →
# Secrets and variables → Actions → Variables); unset vars fall back
# to the action's defaults. Inputs whose default is empty
# (fallback_model, max_findings) pass empty when the var is unset —
# identical to omitting them.
- uses: aliasunder/umm-actually@a2b6b24cf1e7d7b6f9892b092e240780c7a2118e # v0.4.4
# Secrets and variables → Actions → Variables). Unset vars use the action
# default unless the expression below supplies an explicit workflow default.
# Inputs whose default is empty (fallback_model, max_findings) pass empty
# when the var is unset — identical to omitting them.
Comment thread
aliasunder marked this conversation as resolved.
- uses: aliasunder/umm-actually@d3d9d89743d627e41a07586e97ceace216c7a721 # v0.4.5
with:
github_token: ${{ steps.app-token.outputs.token }}
openrouter_api_key: ${{ secrets.OPENROUTER_KEY }}
Expand All @@ -100,8 +100,11 @@ jobs:
# output. Empty = no fallback
fallback_model: ${{ vars.UMM_FALLBACK_MODEL }}
# Per-attempt cap on a single model request; a timed-out attempt
# aborts and advances the retry/fallback ladder. Empty = 600
# aborts and advances the retry/fallback ladder. Empty = 900
request_timeout_seconds: ${{ vars.UMM_REQUEST_TIMEOUT_SECONDS }}
# 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 }}
Comment on lines +105 to +107

@umm-actually umm-actually Bot Sep 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

# Positive integer cap on posted findings (highest severity
# first). Empty = uncapped
max_findings: ${{ vars.UMM_MAX_FINDINGS }}
Expand Down