feat(core): configurable subprocess timeout with dedicated error (closes #145) - #183
Closed
Galmanus wants to merge 3 commits into
Closed
feat(core): configurable subprocess timeout with dedicated error (closes #145)#183Galmanus wants to merge 3 commits into
Galmanus wants to merge 3 commits into
Conversation
…ne-b#145) No subprocess/network call in core had a timeout, so a wedged registry or hung process could hang the CLI forever. Add an opt-in `timeout` to RunCommandOptions wired into execa; on timeout throw CaatingaError(COMMAND_TIMEOUT) with an actionable hint. Applied to the two network-facing calls: `npm view` (60s) and the `npx generate` bindings download (120s). Left other calls untimed so a legitimately long deploy isn't cut off. Tests cover the timeout error mapping and the option pass-through.
Contributor
Author
|
Closing to reduce review load on the maintainer side. Happy to reopen or rebase any of these if useful. |
4 tasks
kelvin1738-sys
pushed a commit
to kelvin1738-sys/caatinga
that referenced
this pull request
Sep 8, 2026
…ione-b#145) No subprocess or network call in @caatinga/core had a timeout, so a stalled registry, wedged network, or hung process hung the CLI forever with no error and no recourse. runCommand gains an optional `timeout` wired into execa. A run killed by it (execa's `timedOut`) throws CaatingaError(CAATINGA_COMMAND_TIMEOUT) naming the limit that was exceeded, ahead of the generic failureCode path so the diagnosis is not swallowed. Budgets live in shell/command-timeouts.ts as named constants rather than a single global default. Caatinga drives commands whose legitimate runtime spans four orders of magnitude, so one default is either tight enough to kill real work or loose enough to catch nothing: - 30s version and capability probes (stellar --version, check-binary, stellar keys address, feature probes) - 60s registry lookups (npm view @stellar/stellar-sdk) - 120s bindings generation (npx --yes @stellar/stellar-sdk generate) - 300s Stellar CLI transactions: deploy, upgrade, upload, invoke, read, simulate, post-deploy hooks, contract-id recovery Contract builds and every @caatinga/zk circuit/ceremony command are deliberately left untimed: a cold Cargo compile or a powers-of-tau ceremony legitimately runs for many minutes, and bounding those needs a per-project budget rather than a constant. The 300s bound on transactions also means a mainnet deploy or upgrade can no longer hang indefinitely mid-flight, which is the failure mode the retry loops in Dione-b#138 would otherwise sit on top of. Follows the approach proposed by @Galmanus in Dione-b#183, extended past the two calls the issue named to every network-facing and transaction call site, plus the COMMAND_TIMEOUT-over-failureCode precedence.
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
1 participant
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.
Closes #145
No subprocess or network call in
@caatinga/corehad a timeout, so a stalled registry, wedged network, or hung process could hang the CLI forever with no error or recourse.Fix:
RunCommandOptions.timeout?: number, wired into execa. On a killed-by-timeout run (execa'stimedOut),runCommandthrowsCaatingaError(COMMAND_TIMEOUT)with a hint ("exceeded Ns; check network/registry availability").npm view @stellar/stellar-sdk version(60s) and thenpx --yes @stellar/stellar-sdk generatebindings download (120s, generous since it also builds).stellardeploy) stay untimed, so a legitimately long operation isn't cut off by a global default. NewCOMMAND_TIMEOUTerror code added.Tests: a
timedOutexeca rejection maps toCOMMAND_TIMEOUT; thetimeoutvalue is passed through to execa.tsc --noEmit+ shell/sdk suites pass.