Troubleshooting

Start with the symptom closest to what you see. If none fits, email marcus@cmglabs.ai with the repository, the pull request number and, if the check shows one, the reference id.

No Warpway check on a pull request

Check these in order:

1. Is the pull request a draft? Drafts are skipped unless review.include_drafts: true. Mark it ready for review.
2. Is the repository in the installation? On GitHub, open the installation's repository access and confirm the repository is selected. See GitHub installation.
3. Is reviewing turned on for the repository in the Warpway dashboard?
4. Is the installation suspended? A suspended installation receives no events.
5. Does your configuration exclude it? Authors in review.ignore_authors, base branches outside review.base_branches, and pull requests whose changed files all match review.ignore_paths are not reviewed. Remember the configuration comes from the base branch.
6. Has the pull request changed since installation? Pull requests that were already open are reviewed on their next event. Push a commit or close and reopen the pull request. After the first review exists, /warpway rerun and the dashboard rerun button are available.

The check says "Usage limit reached"

The Free plan includes 20 private repository reviews per calendar month (UTC). The pull request was not reviewed. Upgrade to Team, or wait for the next month and push a commit or re-run the check. See Billing.

The check reports a configuration error

The .warpway.yml on the base branch is invalid. The check's title reads Invalid Warpway configuration, and the check details and the summary comment list each problem with its line, for example an unknown key or a value of the wrong type. Fix the file in a pull request and merge it; until then reviews against that branch report the error instead of passing. The pull request that fixes the file is itself reviewed under the broken base-branch file, so it reports the same error. If Warpway / Review is a required check, either have someone with bypass permission merge the fix, or have an Admin lower the repository's trust level below Gate in the dashboard until it merges: below Gate the check reports neutral and does not block.

Common mistakes:

• a misspelled key, such as merge_gates or required_lens;
• a lens key that does not exist, or uses uppercase letters;
• a glob that starts with * and is not quoted: write "**/*.snap";
• trust_level written as a word instead of a number from 0 to 4.

My change to .warpway.yml has no effect

Warpway reads the configuration from the pull request's base branch, so changes apply to pull requests opened after the change is merged, not to the pull request that makes it. The summary comment on that pull request says so. Also check:

• the file is the one Warpway reads: the first that exists of .warpway.yml, .warpway.yaml, .github/warpway.yml and .github/warpway.yaml. See Configuration as code;
• the key is not locked by your organization (locked keys are ignored and listed with the review);
• your plan includes the feature: on Free, .warpway.yml policy is not applied;
• you are not trying to raise the trust level: the file can only lower it.

The check is neutral and does not block merges

At trust levels 0 (Observe) and 1 (Assist), the check always concludes neutral, which GitHub treats as passing. Raise the repository to Gate and require the check in branch protection. On the Free plan the trust level is capped at Assist. See Merge gating.

Warpway / Review does not appear in branch protection

GitHub only offers checks that ran in the repository recently. Open or update a pull request so the check runs once, then search for it again, spelled exactly Warpway / Review.

A lens is Incomplete

Incomplete means Warpway could not finish required work, so it refuses to call the lens Cleared. The lens shows the reason. Common causes:

• A model or tool failed after retries, for example during a provider outage. Re-run the check.
• A required runtime verification profile failed, timed out or never reported. See the next section.
• Required evidence could not be gathered, for example a lens requires evidence about callers and the code could not be read.
• The pull request is too large for review.max_changed_files, or the repository snapshot could not be downloaded.
• A permission is missing, such as Actions access for runtime verification (install the Warpway Runtime app and give it the repository).

Fix the cause and re-run the check. Incomplete never turns into Cleared on its own.

Runtime verification does not run

• The workflow must exist on your default branch, because GitHub only dispatches workflows it finds there, and on the pull request's base branch, whose copy Warpway runs.
• The profile must be listed under runtime.profiles in the base branch's .warpway.yml, with the right workflow file name.
• Runtime verification must be turned on for the repository, the Warpway Runtime app installed with access to the repository (or Actions: write granted to your Warpway app on a self-hosted deployment), and the organization on the Team plan. The lens's Incomplete reason names which one is missing.
• The pull request must not come from a fork. Warpway never runs fork code with your workflow, which has your repository's permissions and secrets, so a lens that requires a profile stays Incomplete on a fork pull request.
• The workflow must keep the correlation id in its run-name and upload its warpway-result.json in an artifact named warpway-result-<correlation id>, as the template does.

See Runtime verification.

Slack messages are not arriving

• Is Slack connected? Check Settings → Slack. If the app was removed from the workspace, reconnect it.
• Is the person linked? A task goes to Slack only for people whose Slack identity is linked by an explicit link, a verified email match you enabled, or an Admin. See Slack installation.
• Is the person active in Slack? Deactivated members cannot receive messages; Warpway routes to the next candidate.
• Is Slack enabled for the repository? slack.enabled: false in .warpway.yml keeps questions out of Slack.
• Is the organization on a plan with Slack? Slack routing is included in the Team (and trial) and Enterprise plans, not Free.
• Does the question go to Slack? Engineering questions go to people on GitHub. Slack is used for non-engineering questions, people who are only in Slack, and lenses or routing set to prefer_slack. See Routing.
• Is the repository at Observe? At trust level 0 Warpway asks nobody anything.

A task went to the wrong person

The person can answer I'm not the right person, or comment /warpway wrong-person <task reference> on GitHub, and Warpway reroutes it. Admins can reassign the task directly and correct expertise on the People page so future questions route better. See Routing.

My answer did not resolve the task

Warpway resolves a task only when the answer clearly settles the question. If your reply could mean more than one thing, it asks one follow-up; answer that, or use the buttons. See Human tasks.

I was asked again after new commits

Warpway reuses an earlier answer as it is only if the code the question depended on did not change. If the new commits changed that code, Warpway checks the earlier answer against the new code and reopens the task when the answer no longer holds, so you are asked about the new behavior.

Auto-approval did not approve

Open the pull request in the dashboard: auto-approval eligibility lists every condition with whether it passed. The most common reasons are a new commit since the review, an open required task, a failing or missing CI check, a path or category exclusion, a repository below trust level 4 (Auto-approve), or auto-approval not enabled by an Owner for the repository. See Auto-approval.

Merges wait forever in the merge queue

Warpway reviews pull requests and does not report on merge-queue groups. Do not require Warpway / Review in a ruleset that also gates a merge queue. See Merge gating.