multica-ai/multica · error

delete skill: %w

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.

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)

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: %w
• delete comment: %w
• delete runtime: %w
• update skill: %w
• refresh skill: %w

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