Repository navigation
A workflow is persistently red on main #74
Description
Activity
test (mobile)half: fixed inbe689f2bd.Root cause was
ff78583c5("chore(mobile): bump to 0.2.0 and align the App Store version record", 2026-09-08), which rewrotemobile/app.jsonwith expanded arrays instead of prettier's collapsed form. Its parent was prettier-clean.Because
format:checkis the first sub-command ofyarn test, nothing behind it had run in 19 days — and it was hiding a second failure:expo:check(expo install --check) reported 14 outdated Expo SDK packages. That compares against Expo's remote SDK metadata, so it drifts red on its own as Expo publishes patches. Fixingapp.jsonalone would not have made the job green.expo install --fixmoved 12 packages onto their expected patch versions.Full chain now green locally in 49.70s:
format:check,typecheck,lint,test:unit(369 tests),expo:check, plus the codegen gate.This issue's
Render schema drifthalf is still open and is tracked asw1/m165. Both of its jobs fail, for two independent reasons:render-schemaaborts on its own fixture (Render webhook vocabulary fixture is internally inconsistent: docs/render-artifacts/fixtures/render-webhook-vocabulary-2026-08-17.json) before comparing anything — so the REST half has asserted nothing since it shipped. This is exactly the "shipped broken" mode this issue predicted.render-mcpworks correctly and reports real drift:upstream ref=main added=[list_events] removed=[none]. Render registers a tool absent from ADR018,mcp_parity.goand the pinnedrender-mcp-tools.json(22 tools, pinned 2026-08-18).
Leaving the issue open for that half.
- added a commit that references this issue
on Sep 28, 2026 Render schema drift: the narrowed scope from w1/m165 is now in place. Shipped in 1d07a8b; first
workflow_dispatchrun is 36970184053.render-mcp: passes, the first green run this job has had. Upstreamlist_eventsis implemented 1:1, and the pin was re-captured atd9a8abd5.render-schema: still red, but only on real upstream drift. Render'srender.yaml.jsonhas addedbuildSources,workflowServiceand a plan split. The failure now names that drift and the decision it needs. The webhook half passes. The Blueprint re-pin is tracked as w1/117 and will turn this job green once it lands.
The "check shipped broken" half of this issue is resolved. What still holds this workflow red is a real parity decision, tracked as w1/117.
No workflow is failing persistently on main any more.
Workflows failing persistently on main (threshold: 3 consecutive runs):
govulncheck (Go workspace) — 47 consecutive failures
Last good:
ac348f31f. First failure:182af1ee8(2026-10-01T21:11).https://github.com/bex-co/bex/actions/runs/36926994682
scripts (test) — 21 consecutive failures
Last good:
8c5bc2467. First failure:1e6b70ed4(2026-10-02T07:37).https://github.com/bex-co/bex/actions/runs/36979529540
test (mobile) — 8 consecutive failures
Last good:
aefa4d931. First failure:e97ca4227(2026-10-02T05:32).https://github.com/bex-co/bex/actions/runs/36969401129
Render schema drift — 6 consecutive failures
Never passed in the runs inspected. The check may have shipped broken.
https://github.com/bex-co/bex/actions/runs/32701884937
A check this red is not reporting anything. Either the assertion is wrong — as
in
d82cc98cd, where a yq expression returned one line per document and socould never compare equal, failing regardless of the manifest — or it is right
and something has been broken for as long as the streak.
Fix it or delete it. Leaving it red is the one option that costs something: it
normalizes a red workflow, and the next genuine failure goes unread.