multica-ai/multica · error

update failed: %w

Error message

update failed: %w

What it means

The direct-download update path (cli.UpdateViaDownloadWithTimeout) failed while fetching or applying the release archive for the resolved target version. The wrapped error carries the concrete cause: context deadline exceeded when --download-timeout is too small, 404 when the expected asset is missing for the platform, or write/replace failures on the binary.

Source

Thrown at server/cmd/multica/cmd_update.go:67

		fmt.Fprintln(os.Stderr, "Updating via Homebrew...")
		output, err := cli.UpdateViaBrew()
		if err != nil {
			fmt.Fprintf(os.Stderr, "%s\n", output)
			return fmt.Errorf("brew upgrade failed: %w\nYou can try manually: brew upgrade multica-ai/tap/multica", err)
		}
		fmt.Fprintln(os.Stderr, "Update complete.")
		return nil
	}

	// Not installed via brew — download binary directly from GitHub Releases.
	if latest == nil {
		return fmt.Errorf("could not determine latest version; check https://github.com/multica-ai/multica/releases/latest")
	}
	targetVersion := latest.TagName
	fmt.Fprintf(os.Stderr, "Downloading %s from GitHub Releases...\n", targetVersion)
	output, err := cli.UpdateViaDownloadWithTimeout(targetVersion, updateDownloadTimeout)
	if err != nil {
		return fmt.Errorf("update failed: %w", err)
	}
	fmt.Fprintf(os.Stderr, "%s\nUpdate complete.\n", output)
	return nil
}

View on GitHub (pinned to 2c0912b6ec)

Solutions

1. Read the wrapped error: 'context deadline exceeded' → rerun with a larger timeout, e.g. `--download-timeout 10m`.
2. 404 / asset error → verify the release at github.com/multica-ai/multica/releases has an asset matching your OS/arch.
3. Permission error → ensure the directory containing the multica binary is writable by the current user.
4. Persistent failures → reinstall via Homebrew or download the archive manually.

Example fix

# before
multica update --download-timeout 30s   # update failed: context deadline exceeded

# after
multica update --download-timeout 10m

DFL=$(command -v multica); [ -w "$(dirname "$DFL")" ] && echo 'binary dir writable' || echo 'update will fail: no write access'

if ! multica update --download-timeout 10m; then echo 'download update failed; trying manual release download'; # fetch archive from releases page as fallback
fi

When it happens

Trigger: Running `multica update` (non-brew) with a slow link and a tight --download-timeout (deadline exceeded), on an OS/arch for which the release has no asset (404), or when the running binary's directory is not writable so the self-replace fails.

Common situations: Slow CI networks, exotic platforms without published release assets, installing to system paths without write permission, or hitting a half-published release where the tag exists but assets are still uploading.

Related errors

• get attachment: %w
• download file: %w
• install Private Plugin: %w
• brew upgrade failed: %w You can try manually: brew upgrade m
• could not determine latest version; check https://github.com

AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15). Data as JSON: /api/errors/0c5226b3e9264fb7. Report an issue: GitHub.