larksuite/cli · error

skills update timed out after %s

Error message

skills update timed out after %s

What it means

runSkillsCommandInDir executes the skills subcommand (staging/updating suites) with a context bounded by skillsUpdateTimeout. If the command outlives the deadline, the context cancels it and this error replaces the exec result to indicate a timeout.

Source

Thrown at internal/selfupdate/updater.go:421

		return u.SkillsCommandOverride(args...)
	}
	r := &NpmResult{}
	det := u.DetectInstallMethod()
	launcher, cmdArgs := skillsInvocation(det.Method, det.PnpmAvailable, args)
	binPath, err := exec.LookPath(launcher)
	if err != nil {
		r.Err = fmt.Errorf("%s not found in PATH: %w", launcher, err)
		return r
	}
	ctx, cancel := context.WithTimeout(context.Background(), skillsUpdateTimeout)
	defer cancel()
	cmd := exec.CommandContext(ctx, binPath, cmdArgs...)
	cmd.Dir = dir
	cmd.Stdout = &r.Stdout
	cmd.Stderr = &r.Stderr
	r.Err = cmd.Run()
	if ctx.Err() == context.DeadlineExceeded {
		r.Err = fmt.Errorf("skills update timed out after %s", skillsUpdateTimeout)
	}
	return r
}

// VerifyBinary checks that the installed binary reports the expected version
// by running "lark-cli --version" and comparing the version token exactly.
// Output format is "lark-cli version X.Y.Z"; the last field is extracted and
// compared against expectedVersion (both stripped of any "v" prefix).
func (u *Updater) VerifyBinary(expectedVersion string) error {
	if u.VerifyOverride != nil {
		return u.VerifyOverride(expectedVersion)
	}
	// Prefer PATH resolution so npm global bin symlinks pick up the newly
	// installed binary (#836). If `lark-cli` is not on PATH (e.g. the user
	// invoked this process by absolute path), fall back to the running
	// executable — same as the pre-#836 secondary resolution path.
	exe, err := execLookPath("lark-cli")
	if err != nil {

View on GitHub (pinned to 7fd6ef3c07)

Solutions

1. Check network/registry reachability and retry the skills command once connectivity is stable
2. Run the underlying package-manager command manually (e.g. `pnpm add -g @larksuite/cli`) to complete outside the timeout
3. Reduce work by updating only the needed skills suites instead of all suites
4. Use a faster registry mirror to speed up the package-manager operation

Example fix

// before
res := updater.StageSuite(dir, args)
if res.Err != nil { log.Fatal(res.Err) }
// after
res := updater.StageSuite(dir, args)
if res.Err != nil {
	if strings.Contains(res.Err.Error(), "timed out") {
		log.Printf("skills command timed out; check network and retry: %v", res.Err)
	} else {
		log.Fatal(res.Err)
	}
}

if _, err := exec.LookPath("npm"); err != nil { return } // launcher present
// optionally probe registry latency before long skills updates

res := stageResult
if res.Err != nil {
	if strings.Contains(res.Err.Error(), "timed out after") {
		// retry once on a stable network, or run the package-manager command manually
	} else {
		return res.Err
	}
}

When it happens

Trigger: Invoking skills operations via StageSuite or runSkillsCommand (e.g. skills update/install) when the spawned npm/pnpm command runs longer than skillsUpdateTimeout, so ctx.Err() == context.DeadlineExceeded after cmd.Run().

Common situations: Slow network during skills package download; large skills suite updates; npm/pnpm waiting on registry under a proxy; congested CI runner or throttled connection.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• npm install timed out after %s
• pnpm install timed out after %s
• %s not found in PATH: %w
• lark-cli timed out after {timeout}s
• poll network error: %w

AI-assisted analysis of larksuite/cli@7fd6ef3c07 (2026-09-04). Data as JSON: /api/errors/e9e79fe3abecc66c. Report an issue: GitHub.