Summary
No subprocess or network call in @caatinga/core has a timeout:
runCommand passes no timeout to execa (packages/core/src/shell/run-command.ts:31-37)
checkStellarSdkVersion shells out to npm view @stellar/stellar-sdk version (packages/core/src/stellar-sdk/check-stellar-sdk-version.ts:29-34) — a network call
generateBindings runs npx --yes ... which downloads a package from the registry on every generate (packages/core/src/contracts/generate-bindings.ts:70-89)
Why it matters
A stalled registry, wedged network, or hung stellar process hangs the CLI forever with no error, no hint, and no user recourse.
Suggested fix
- Add a configurable
timeout (e.g. 60s) to RunCommandOptions and wire it into the npm view / npx calls
- On timeout, throw a
CaatingaError with a hint (e.g. "the command exceeded 60s; check network/registry availability")
- Test: a sleeping command times out and surfaces the dedicated error
Priority: High | Release impact: Patch | Breaking: No
Summary
No subprocess or network call in
@caatinga/corehas a timeout:runCommandpasses notimeoutto execa (packages/core/src/shell/run-command.ts:31-37)checkStellarSdkVersionshells out tonpm view @stellar/stellar-sdk version(packages/core/src/stellar-sdk/check-stellar-sdk-version.ts:29-34) — a network callgenerateBindingsrunsnpx --yes ...which downloads a package from the registry on every generate (packages/core/src/contracts/generate-bindings.ts:70-89)Why it matters
A stalled registry, wedged network, or hung
stellarprocess hangs the CLI forever with no error, no hint, and no user recourse.Suggested fix
timeout(e.g. 60s) toRunCommandOptionsand wire it into thenpm view/npxcallsCaatingaErrorwith a hint (e.g. "the command exceeded 60s; check network/registry availability")Priority: High | Release impact: Patch | Breaking: No