fix(api): preflight missing repository before builder dispatch - #168
fix(api): preflight missing repository before builder dispatch#168elirethDev wants to merge 2 commits into
Conversation
…nce checks are configured A delivery-mode run without acceptance checks (check_cmds empty) and without a GitHub-backed repo used to provision a full sandbox, spend the budget on the agent run, and only then fail at the runner's delivery gate with checks_not_configured — no branch, no PR, work discarded. - dispatchRun now evaluates the runner's acceptance gate up front (mirrored from runner/src/index.ts: requiresDelivery + githubCiOwnsAcceptance): the run fails immediately with checks_not_configured before any sandbox or spend-capable key exists. - web issue trigger and slash-command routing refuse to insert the run (409 / routed:false) under the same predicate, resolving check commands with the buildRunBundle precedence (profile override, repo render answers, project settings). - the session page renders the checks_not_configured JSON failure as a human explanation with a link to the project settings gates editor via a small tested error-code mapping helper; unknown errors still render raw. Per the runner's semantics, GitHub-backed repos remain exempt: their CI owns acceptance of the signed draft PR.
| // owns acceptance. | ||
| export function checksConfiguredForDispatch(bundle: AcceptanceBundle): boolean { | ||
| return ( | ||
| githubCiOwnsAcceptance(bundle) || !requiresDelivery(bundle.mode) || bundle.checkCmds.length > 0 |
There was a problem hiding this comment.
This doesn’t seem to catch the case from #28 anymore. checksConfiguredForRepo() gives every connected repo a GitHub URL, so this always passes for a builder even when checkCmds is empty. The only builder it blocks has no repo; asking that user to configure checks is misleading, because the run will then start and fail with delivery_repo_not_configured. Could we either preflight the missing repo too, or re-scope this now that GitHub CI owns acceptance?
There was a problem hiding this comment.
Mmm, yeah, you're right. Looking at the current flow, I think the right thing to do is:
- replace the current API-side checks preflight with an early
delivery_repo_not_configuredguard for builder runs without a repository, before creating keys or provisioning a sandbox; - remove the
checksConfiguredForRepo()preflight from connected GitHub repository triggers; - add human-readable UI copy and regression tests for that failure mode;
- update the PR description to make it clear that GitHub CI owns acceptance for connected repositories.
That way, connected repositories follow the current GitHub CI acceptance model, while builder runs without a repository fail early instead of spending resources on a run that cannot deliver.
There was a problem hiding this comment.
Implemented in 19d5d88.
Connected GitHub repositories no longer run the check-command preflight. Builder runs without a repository now fail before key creation or sandbox provisioning with delivery_repo_not_configured, with matching UI copy and regression coverage. I also updated the PR title and description to reflect the current GitHub CI acceptance model.
Focused checks pass: 32 API tests, 8 web tests, both typechecks, Biome, and diff whitespace checks.
There was a problem hiding this comment.
I reran the database-backed suites with Docker and Postgres healthy. The result was 90 passed, 1 timing-based timeout in coalesces a CI notification burst, and no skipped tests.
I also confirmed that pnpm verify still stops at its first Lint step on Windows with scripts/verify.mjs calling spawnSync("pnpm") and receiving ENOENT.
elirethDev
changed the title
2 participants
Related to #28.
What changes
A builder run without a repository cannot create a branch or pull request. Before this change, it could provision the sandbox and spend the run budget before the runner reported
delivery_repo_not_configured.dispatchRunnow fails a builder without a repository before the atomic claim, spend-capable key creation, or sandbox provisioning, usingdelivery_repo_not_configured.delivery_repo_not_configuredas a human explanation with a link to project Settings. Unknown errors still render raw, and the existingchecks_not_configuredpresentation remains available as a runner backstop.The connected-repository/no-kickstart scenario described in #28 appears to have been superseded by the current GitHub-CI-owned acceptance model. The repo-connect prompt from the original issue remains outside this change.
Files
services/api/src/sandbox/delivery-gate.tsservices/api/src/sandbox/orchestrator.tsservices/api/src/routes/v1/github.ts,services/api/src/github/router.tsapps/web/components/run/run-error.tsdelivery_repo_not_configuredpresentationservices/api/test/*,apps/web/test/run-error.test.tsVerification
github-platform-lane.test.ts(coalesces a CI notification burst), 0 skipped; the database-backed suites ran with Docker/Postgres healthypnpm --filter @facility/api typecheckandpnpm --filter @facility/web typecheck: passpnpm exec biome checkon the changed files: cleangit diff HEAD^ HEAD --check: cleanpnpm verifyremains blocked at its first Lint step by the existing Windowsscripts/verify.mjsspawnSync("pnpm")issue (ENOENT); the full acceptance suite remains for CI.