multica-ai/multica · error

delete trigger: %w

Error message

delete trigger: %w

What it means

Wrapped error from DELETE /api/autopilots/{id}/triggers/{triggerID} in `multica autopilot trigger delete`. Both references resolved successfully; the server-side deletion failed. For schedule triggers the server also stops the associated cron schedule as part of the delete, so failures can originate from either the trigger row removal or schedule teardown.

Source

Thrown at server/cmd/multica/cmd_autopilot.go:735

	if err != nil {
		return err
	}

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

	autopilotRef, err := resolveAutopilotID(ctx, client, args[0])
	if err != nil {
		return fmt.Errorf("resolve autopilot: %w", err)
	}
	triggerRef, err := resolveAutopilotTriggerID(ctx, client, autopilotRef.ID, args[1])
	if err != nil {
		return fmt.Errorf("resolve trigger: %w", err)
	}

	path := "/api/autopilots/" + autopilotRef.ID + "/triggers/" + triggerRef.ID
	if err := client.DeleteJSON(ctx, path); err != nil {
		return fmt.Errorf("delete trigger: %w", err)
	}
	fmt.Printf("Trigger %s deleted.\n", triggerRef.ID)
	return nil
}

func resolveAutopilotSubscriberInputs(ctx context.Context, client *cli.APIClient, refs []string) ([]map[string]string, error) {
	inputs := make([]map[string]string, 0, len(refs))
	seen := map[string]struct{}{}
	memberOnly := assigneeKinds{member: true}
	for _, ref := range refs {
		if strings.TrimSpace(ref) == "" {
			return nil, fmt.Errorf("--subscriber cannot be empty")
		}
		userType, userID, err := resolveAssignee(ctx, client, ref, memberOnly)
		if err != nil {
			return nil, fmt.Errorf("resolve subscriber %q: %w", ref, err)
		}
		if userType != "member" {

View on GitHub (pinned to 2c0912b6ec)

Solutions

  1. On 404, treat as already-deleted (idempotent success)
  2. Wait for in-flight runs to finish or force-stop them before deleting a schedule trigger
  3. Grant/refresh credentials on 401/403
  4. Retry transient 5xx/network errors once

Example fix

// before (script fails on double-run)
multica autopilot trigger delete my-pilot tr1 || exit 1

// after (idempotent)
out=$(multica autopilot trigger delete my-pilot tr1 2>&1)
if [ $? -ne 0 ] && [[ "$out" != *"404"* ]]; then echo "$out"; exit 1; fi
Defensive patterns

Strategy: fallback

Validate before calling

TRIGGER=$(curl -s -H "Authorization: Bearer $TOKEN" "$API/api/autopilots/$ID" | jq -r --arg t "$T" ".triggers[] | select(.id==\"$t\") | .id")
[ -n "$TRIGGER" ] || { echo "trigger already absent"; exit 0; }

Try / catch

Run the delete; on failure parse the wrapped status — 404 => succeed silently (already deleted), 409 => wait for the in-flight run and retry, 401/403 => abort with credentials error, 5xx/network => one retry with backoff.

Prevention

When it happens

Trigger: DELETE returning 404 when the trigger was deleted concurrently (classic double-run), 403 without delete permission, 409 when a run started from this trigger is still executing and the server refuses teardown, 5xx, or a network failure under cli.APIContext.

Common situations: Two operators (or a script and a human) deleting the same trigger; service accounts lacking delete scope; deleting a schedule trigger mid-run.

Related errors


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