multica-ai/multica · error

delete skill

Error message

delete skill: %w

What it means

Returned by the `multica skill delete` CLI subcommand when the DELETE request to `/api/skills/{id}` fails. Because the client error is wrapped with %w, the message carries the true cause: connection failure, timeout, or a non-2xx status — a 404 (no skill with that ID) is by far the most common. No request body is sent, so payload validation is never the issue.

Solutions

1. Confirm whether the skill still exists: `multica skill list` — if it is gone, the delete already succeeded and the error can be ignored.
2. Re-check the exact ID/argument; IDs are positional args and easy to truncate when copying.
3. Verify connectivity/auth: `multica skill list` against the same --api-url; if that also fails, fix the environment before retrying the delete.
4. If the server returns 500, inspect server logs — the repository enforces application-layer cleanup for dependent rows (no DB cascades), so a cleanup bug surfaces here.

Example fix

// before
multica skill delete old-skill-id   # fails if already deleted

// after
multica skill list --output json | jq '.[].id'  # confirm current IDs
multica skill delete <confirmed-id>

# make deletes idempotent: check existence first
if multica skill get "$SKILL_ID" --output json > /dev/null 2>&1; then
  multica skill delete "$SKILL_ID"
else
  echo "skill already absent"
fi

Treat 404-in-message as already-deleted and exit 0 in automation; retry only on 5xx/connection errors; never retry a 400 blindly. Log the raw wrapped error for audit since deletes are destructive.

When it happens

Trigger: `multica skill delete <id>` with an ID that was already deleted or never existed (404); server down/unreachable; auth credentials invalid so the API returns 401/403; server-side cascading cleanup fails and returns 500.

Common situations: Running the same delete twice (e.g. a script retried after a partial failure); ID copied from stale output; deleting a skill that another process removed concurrently; pointing at a fresh dev database.

Related errors

• delete skill file
• delete comment
• delete runtime
• import skill
• list skill files

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

Appendix: source

Thrown at server/cmd/multica/cmd_skill.go:418

		reader := bufio.NewReader(os.Stdin)
		answer, _ := reader.ReadString('\n')
		answer = strings.TrimSpace(strings.ToLower(answer))
		if answer != "y" && answer != "yes" {
			fmt.Println("Aborted.")
			return nil
		}
	}

	client, err := newAPIClient(cmd)
	if err != nil {
		return err
	}

	ctx, cancel := cli.APIContext(context.Background())
	defer cancel()

	if err := client.DeleteJSON(ctx, "/api/skills/"+args[0]); err != nil {
		return fmt.Errorf("delete skill: %w", err)
	}

	fmt.Printf("Skill deleted: %s\n", args[0])
	return nil
}

func runSkillRefresh(cmd *cobra.Command, args []string) error {
	client, err := newAPIClient(cmd)
	if err != nil {
		return err
	}

	// The server re-fetches the bundle from the upstream source before
	// answering; give it the same budget as an import (server-side cap: 45s).
	ctx, cancel := context.WithTimeout(context.Background(), cli.AtLeastAPITimeout(60*time.Second))
	defer cancel()

	var result map[string]any

View on GitHub (pinned to 2c0912b6ec)