lark-cli update reports binary verification failure on Linux global npm install, but package is updated

[liushuaiiu]

Summary

Running lark-cli update from 1.0.26 to 1.0.28 on a Linux global npm installation reported a binary verification failure:

new binary verification failed: binary not executable:
fork/exec <global-npm-prefix>/@larksuite/.cli-<temp>/bin/lark-cli:
no such file or directory

automatic rollback is unavailable on this platform;
reinstall manually: npm install -g @larksuite/cli@1.0.28

However, after the command reported failure, the global installation appeared to be successfully updated to 1.0.28, and lark-cli was usable.

Environment

OS: Linux
Install method: npm global install
Previous version: 1.0.26
Target version: 1.0.28
Node/npm: global npm environment

What happened

Command:

lark-cli update

Output:

Updating lark-cli 1.0.26 → 1.0.28 via npm ...

✗ new binary verification failed: binary not executable:
fork/exec <global-npm-prefix>/@larksuite/.cli-<temp>/bin/lark-cli:
no such file or directory

automatic rollback is unavailable on this platform;
reinstall manually: npm install -g @larksuite/cli@1.0.28,
or download https://github.com/larksuite/cli/releases/tag/v1.0.28

Afterwards, these checks showed that the CLI was actually updated and working:

lark-cli --version
npm ls -g @larksuite/cli --depth=0
lark-cli --help

Observed result:

lark-cli version 1.0.28
@larksuite/cli@1.0.28

lark-cli --help also worked normally.

Expected behavior

If the update succeeds, lark-cli update should not report a failed binary verification.

If verification fails, the final installation state should be clear:

• whether the update was actually applied
• whether rollback happened
• what command the user should run next
• whether the current CLI remains usable

Actual behavior

The update command reported failure during verification, but the final installed package was already 1.0.28 and executable.

This makes the result ambiguous: the user sees an error suggesting manual reinstall, while the CLI is already updated and working.

Possible cause

The updater appears to verify the temporary package using a path like:

<global-npm-prefix>/@larksuite/.cli-<temp>/bin/lark-cli

But the final globally installed executable may resolve through the installed package entrypoint instead. The self-updater may be assuming a temporary binary path that is not yet present, not executable, or not aligned with the package's actual installed entrypoint during the temporary verification phase.

Possible related causes:

1. temporary install/extract not completed before verification
2. mismatch between expected temporary bin/lark-cli and final npm entrypoint
3. Linux global npm prefix/symlink behavior not fully handled
4. self-update rollback/verification path not robust on this platform

Impact

Low/medium severity.

The CLI appears usable after the failed update, but the error is confusing and may lead users to reinstall unnecessarily. It also makes automated update flows harder to trust.

Suggested fix

Consider one or more of:

1. Verify the final resolved executable after npm install, e.g. lark-cli --version, instead of only checking the temporary binary path.
2. If temporary verification fails but final install succeeds, report a warning instead of a hard failure.
3. Improve the error message to include current detected version and whether the executable is still usable.
4. Handle Linux global npm prefix rollback/verification explicitly.
5. Add an e2e test for lark-cli update in Linux global npm installation mode.

Additional notes

This was observed during upgrade from 1.0.26 to 1.0.28. After the failed verification message, lark-cli --version reported 1.0.28 and normal commands worked.

[evandance]

Thanks for the detailed write-up and reproducer — this is a real bug and your diagnosis lands on the right fix even though the underlying mechanism is slightly different from what you describe.

Looking at internal/selfupdate/updater.go:185-219, VerifyBinary calls os.Executable() and re-execs that path without re-resolving via PATH. The inline comment at L189-192 assumes "the path itself is still valid for execution" after an npm install, but that assumption breaks on Linux global npm: once npm install -g finishes, it tears down the old @larksuite/.cli-<random> staging directory entirely. The running process's launch path now points at an unlinked file, and exec.CommandContext fails with ENOENT — which gets wrapped as "binary not executable: fork/exec ...". The install itself succeeded, which is why --version and npm ls -g both correctly report 1.0.28. So it's not a pre-install probe race; it's a stale launch path after npm rewrites the symlink and removes the old dir. PrepareSelfReplace is a no-op on Unix (updater_unix.go:10) — there's no temp path we're checking; what you see in the message is npm's own staging dir naming.

Your proposals (a) and (b) both land on the fix: re-resolve via exec.LookPath("lark-cli") after install completes and treat that as the source of truth; if the resolved binary verifies fine, don't surface the stale-launch-path failure as an error. (e) is welcome too — a Linux-global-npm e2e against a tmp prefix would have caught this. We'd be happy to review a PR covering (a)+(b)+(e). (c) and (d) are reasonable but let's leave the exact shape to PR review.