Skip to content

fix(cli): make 'bin/rune' bootstrap stable#166

Open
esifea wants to merge 2 commits into
CryptoLabInc:release/v0.4.1from
esifea:feat/esifea/cli-stabilize
Open

fix(cli): make 'bin/rune' bootstrap stable#166
esifea wants to merge 2 commits into
CryptoLabInc:release/v0.4.1from
esifea:feat/esifea/cli-stabilize

Conversation

@esifea

@esifea esifea commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

Summary

  • What changed: bin/rune
    • Each fetching step retry on failure with curl --retry --retry-max-time considering subcommand mcp-server/install
    • Bootstrap lock record owner as <pid> <timestamp> for checking ownership, and reclaim stale lock
  • Why:
    • If bootstrap exceed Claude Code's MCP spawn timeout (~30s), process could be SIGKILLed and poison every subsequent steps like unreleased lock. So retry ensure bounded spawn budget and reclaim-lock can support self-healing
  • Scope: bin/rune

Notes for Reviewers

  • Risk areas:
  • Backward compatibility impact:
  • Follow-up work (if any): Add proper tests for bootstrap

@esifea esifea self-assigned this Jun 9, 2026
@esifea esifea marked this pull request as ready for review June 9, 2026 07:48
Comment thread bin/rune

@zake-dev zake-dev left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two minor inline notes (retry semantics + typos). Nothing blocking.

Comment thread bin/rune
fetch() {
curl --fail --silent --show-error --location --connect-timeout 5 \
--retry "$NET_RETRY" --retry-delay "$NET_RETRY_DELAY" \
--retry-max-time "$NET_RETRY_MAXTIME" "$@"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Retry rarely fires for slow responses under the mcp-server budget. Here --retry-max-time is 3s, but each call adds a larger --max-time (binary = 10s, see L66). When a request hangs, the single attempt runs to its --max-time, by which point the 3s retry window is already closed, so no retry happens. --retry only helps fast failures (e.g. an immediate HTTP 504). So the comment on L72 ("rides out ... timeouts") slightly overstates it — retries cover fast errors, not slow/hung ones. Suggestion: tweak the comment to say "fast transient errors", and consider --retry-all-errors if you also want mid-transfer resets retried. (Not blocking.)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No retry on slow response is intended but I think comment is not proper. I'll fix this soon.

Or do you think it is better to add --retry-all-errors rather than ignore?

@jh-lee-cryptolab jh-lee-cryptolab Jun 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed — comment fix is enough.

It won't change the slow-response behavior anyway (that comes from --retry-max-time 3s < --max-time 10s, i.e. timing, not error type).
It would also retry permanent errors like a 404 missing asset — on the non-mcp path (60s window) that turns a fast "not found" into a slow failure.
So keep default --retry and just reword, e.g. "retries fast transient errors only; slow/hung requests are intentionally not retried to stay within the spawn budget." 👍

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Comment thread bin/rune Outdated
}

# Network time budget
# - `mcp-server`: MCP entryponit run by Claude Code session with ~30s timeout.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typos in comments (no logic impact):

  • L59 entryponit -> entrypoint
  • L83 stucked -> stuck
  • L124 lokc -> lock

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

zake-dev

This comment was marked as duplicate.

@CryptoLabInc CryptoLabInc deleted a comment from zake-dev Jun 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants