Workers Builds: chittyfinance — instant 0s failure on every PR + main

[chitcommit]

Symptom

The CF Workers Builds GitHub check on every recent PR and on main reports failure after 0 seconds (started_at == completed_at):

PR	Status
#108 (merged)	Workers Builds: FAILURE
#109 (open)	Workers Builds: FAILURE
#110 (open)	Workers Builds: FAILURE
main HEAD	Workers Builds: failure

The check completes instantly with no actual build output, e.g.:

started:   2026-04-30T19:10:59Z
completed: 2026-04-30T19:10:59Z

What it is not

• Not a code/wrangler issue — npx tsx identity/scripts/validate-fractal-scopes.ts passes against both wrangler.jsonc and deploy/system-wrangler.jsonc
• Not a Hyperdrive provisioning issue — both CHITTYOS_CORE_DB (1d12...d15a) and SERVICE_SCOPE_DB (8915...ea7b) exist in account 0bc21e3a5a9de1a4cc843be9c3e98121
• Not a recent regression — at least feat: inbound email handler for finance@chitty.cc #108 (merged 2026-04-24) shows the same 0s failure

Likely cause (hypothesis)

CF Workers Builds integration is misconfigured at the Cloudflare side — the build is being short-circuited before any actual build step runs. Possibilities:

• Build configured against the wrong branch/path filter
• Two competing wrangler files (wrangler.jsonc at root vs deploy/system-wrangler.jsonc) confusing the integration
• Build command empty / node_version unset / repo connection stale

Action requested

Inspect the build at https://dash.cloudflare.com/0bc21e3a5a9de1a4cc843be9c3e98121/workers/services/view/chittyfinance/production/builds/cd3b46ca-bb7d-4c39-8961-91e72a75eef7 and either:

1. Fix the CF integration config, OR
2. Disable Workers Builds and rely on wrangler deploy from the existing GH Actions deploy workflow (current state is "always-red required check")

This is currently masking real build failures — auto-merge has to ignore Workers Builds to land any PR. PR #108 was merged through this state on 2026-04-24.

[chitcommit]

Investigation findings (2026-05-01)

Confirmed

• Worker chittyfinance exists in CF account 0bc21e3a5a9de1a4cc843be9c3e98121 (id 28bfe059dd05458d8a470b5c73eb78a9)
• Wrangler build.command is set: npx vite build --outDir dist/public (in both root wrangler.jsonc and deploy/system-wrangler.jsonc)
• No wrangler deploy GitHub Actions workflow exists in .github/workflows/ — deploys happen manually via npm run deploy (per CLAUDE.md)
• Workers Builds completes in 0 seconds (started_at == completed_at) — not even attempting a real build, suggests a CF integration-side rejection

Likely root cause

The CF Workers Builds integration is enabled at the dashboard for this Worker but is misconfigured — almost certainly one of:

1. Build skipped due to filter mismatch (path/branch filter pointing somewhere that never matches)
2. Build short-circuited due to a stale/broken repo connection
3. Two competing wrangler files (wrangler.jsonc root vs deploy/system-wrangler.jsonc) confusing path detection

Two paths forward

Option A — Fix the CF integration (no code change, dashboard-only)

• Inspect: https://dash.cloudflare.com/0bc21e3a5a9de1a4cc843be9c3e98121/workers/services/view/chittyfinance/production/integrations
• Check the Git integration's branch filter, path filter, and repo connection
• If integration is stale, disconnect and reconnect; if not needed, disable it (it's a required check that's always failing)

Option B — Replace with GH Actions (recommended)
Disable the CF integration at the dashboard, add .github/workflows/deploy.yml that runs wrangler deploy on push to main using the existing manual flow. Pattern from other ChittyOS services in this account.

Recommendation: Option A short-term (quick disable so PRs stop being force-merged through a red required check), Option B medium-term for proper CI/CD.

[chitcommit]

Correction (2026-05-01)

CF Workers Builds is the intended deploy path. The team migrated off GH Actions due to:

1. GH Actions usage limits
2. CF Workers Builds is automatic on commit

So Option B (GH Actions deploy.yml) is off the table. The fix has to be inside the CF Workers Builds integration itself, not by replacing it.

Refined investigation

The 0s failure is suspicious because the Worker IS deployed and serving — meaning some build mechanism is succeeding. Hypothesis: there are multiple builds firing per commit (e.g., duplicate webhook triggers, or both a watcher + a manual hook), one succeeds and deploys, the others fail instantly and post the failure to GitHub.

Things to check at the CF dashboard (https://dash.cloudflare.com/0bc21e3a5a9de1a4cc843be9c3e98121/workers/services/view/chittyfinance/production/integrations):

1. Is there more than one git integration / webhook attached to this repo?
2. Build history — for any single commit, are there multiple build records (some pass, some 0s-fail)?
3. Check filters: which builds are configured to post status to GitHub, and which build's status is being reported?
4. Compatibility date on builds — last build commit date vs compatibility_date: "2026-03-01" in wrangler

If duplicates: remove the rogue trigger.
If single-trigger but always failing: check the build pre-step (often a "skip if no changes" filter that returns success-as-failure).

[chitcommit]

Root cause via CF API (2026-05-01)

Hit the CF Workers Builds API directly. Worker tag 28bfe059dd05458d8a470b5c73eb78a9. Two triggers configured:

Trigger	Branches	Build	Deploy
Deploy default branch	main	pnpm run build	npx wrangler deploy
Deploy non-production	* (excl. main)	pnpm run build	npx wrangler versions upload

Every one of the last 15 builds has status stopped with empty commit_hash. Builds never run — they're being stopped before any code executes. That's why the GH check is 0s and shows failure.

Likely causes:

1. Auto-cancel-on-newer-push firing too aggressively (each new push stops the prior build before it can start)
2. Hooks/preconditions stopping the build before commit info is even captured
3. The triggers were created 2026-03-04 — but wrangler.jsonc was migrated TOML→JSONC on PR refactor: convert wrangler config from TOML to JSONC #104 (2026-04-23). Worth checking if the trigger config still expects TOML.

Also notable: build_command is pnpm run build but the repo uses npm (package.json scripts assume npm). If builds ever actually ran, they'd fail at the build step.

Suggested fix path (no dashboard needed — all via CF API):

1. Update both triggers' build_command from pnpm run build → npm run build
2. Investigate why builds enter stopped state — fetch logs via GET /accounts/{aid}/builds/builds/{uuid}/logs for one of the recent stopped builds
3. If auto-cancel is the cause, tune trigger config

API token has access; can patch via PUT /accounts/{aid}/builds/triggers/{trigger_uuid} once root cause is confirmed.