Soft-fail by default inside build hooks so connector errors never break deploys#44
Open
ejntaylor wants to merge 1 commit into
Open
Soft-fail by default inside build hooks so connector errors never break deploys#44ejntaylor wants to merge 1 commit into
ejntaylor wants to merge 1 commit into
Conversation
…ak deploys A Lovable publish failed with `script "postbuild" exited with code 1`: the platform's agent wired `"postbuild": "patchstack-connect verify"` — a subcommand that has never existed — so the CLI printed its full help to stderr and exited 1, taking the customer's whole deploy down. Truncated platform logs made it worse: the help wall pushed the actual `Unknown command:` line out of view. A security monitor must degrade gracefully in that position. Changes: - Errors are now soft by default inside `prebuild`/`build`/`postbuild` lifecycle scripts (detected via `npm_lifecycle_event`, set by npm, pnpm, yarn, and bun): the CLI reports the error, then exits 0 so the build continues. Manual/interactive runs keep real exit codes. - `PATCHSTACK_SOFT_FAIL` overrides in either direction (`1` forces soft anywhere, `0`/`false`/`no`/`off` restores hard failures even in hooks). Supersedes the opt-in-only approach from #34 — the broken hooks already in the wild carry no env prefix, so opt-in alone never engages. - Unknown-command output is now two short lines with the error last (so tail-truncated build logs show the cause, not a help wall) and includes a did-you-mean suggestion for near-misses like Unicode-dash mangling. - README + AGENT-INSTALL.md now tell agents to use exactly the documented subcommands, and document the soft-fail behavior and env var. Verified end-to-end against a replay of the failing project: a postbuild running `verify` now reports the unknown command and exits 0; the same command manually still exits 1; `PATCHSTACK_SOFT_FAIL=0` in a hook exits 1; a scan network failure in a hook exits 0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Implements soft-fail for build hooks and adds command suggestion for mistyped CLI commands. 🎯 Quality: 93% Elite · 📦 Size: Medium 📈 This month: Your 221st PR — above team average · Averaging Excellent |
Contributor
Author
|
/review |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
A Lovable publish failed with
script "postbuild" exited with code 1even though the app build succeeded. The platform's agent had wired"postbuild": "patchstack-connect verify"— a subcommand that has never existed in any release — so the CLI printed its full help to stderr and exited 1, failing the customer's whole deploy. Lovable truncates stderr from the front, so the help wall pushed the actualUnknown command: verifyline out of view, making the failure look like config-docs noise.AI coding agents are the ones wiring this connector into build scripts, and they sometimes get the invocation wrong. A security monitor should degrade gracefully in that position: report the problem, never take the deploy down with it.
Supersedes #34: that PR's
PATCHSTACK_SOFT_FAILwas opt-in only, but the broken hooks already in the wild carry no env prefix, so the opt-in never engages. This PR keeps the env var (same semantics, credit to #34) and adds the default that actually covers the incident.What
npm_lifecycle_eventisprebuild,build, orpostbuild(npm, pnpm, yarn, and bun all set it), the CLI reports the error then exits 0 so the build continues. Manual/interactive runs (includingnpx, which setsnpm_lifecycle_event=npx) keep real exit codes.PATCHSTACK_SOFT_FAILoverrides in either direction —1(or any truthy value) forces soft anywhere;0/false/no/offrestores hard failures even in hooks. Lives insrc/config.tsassoftFailEnabled(env)with unit tests.mark‑buildwith U+2011 →did you mean `mark-build`?).verifyexplicitly, since that's what the agent invented).Release note
The failing project pins
"@patchstack/connect": "^0.2.8", which caret-resolves to<0.3.0— so besides the next 0.3.x, this needs a 0.2.12 patch release cut from the v0.2.11 tag to reach existing installs.Verification
npx vitest run— 131 tests pass;tsc --noEmitclean.verify→ printsUnknown command: verify+ soft-fail notice,npm run buildexits 0node dist/cli.js verifymanually → exit 1node dist/cli.js mark‑build(Unicode hyphen) →did you mean `mark-build`?, exit 1PATCHSTACK_SOFT_FAIL=0on the postbuild → exit 1 (opt-out honored)scanagainst an unreachable endpoint in a postbuild → printsError (NETWORK_ERROR): …, exits 0🤖 Generated with Claude Code