multica-ai/multica · error

resolve assignee: %w

Error message

resolve assignee: %w

What it means

While listing issues, the CLI tried to turn the --assignee flag (a human name) into an assignee ID via pickAssigneeFromFlags and that lookup failed. The %w wraps the specific cause: the assignee could not be resolved to exactly one actor (not found, ambiguous across the allowed assignee kinds), or the lookup API call itself failed.

Source

Thrown at server/cmd/multica/cmd_issue.go:617

		if _, err := requireWorkspaceID(cmd); err != nil {
			return err
		}
	}

	params := url.Values{}
	params.Set("workspace_id", client.WorkspaceID)
	if v, _ := cmd.Flags().GetString("status"); v != "" {
		params.Set("status", v)
	}
	if v, _ := cmd.Flags().GetString("priority"); v != "" {
		params.Set("priority", v)
	}
	if v, _ := cmd.Flags().GetInt("limit"); v > 0 {
		params.Set("limit", fmt.Sprintf("%d", v))
	}
	_, aID, hasAssignee, resolveErr := pickAssigneeFromFlags(ctx, client, cmd, "assignee", "assignee-id", issueAssigneeKinds)
	if resolveErr != nil {
		return fmt.Errorf("resolve assignee: %w", resolveErr)
	}
	if hasAssignee {
		params.Set("assignee_id", aID)
	}
	if v, _ := cmd.Flags().GetInt("offset"); v > 0 {
		params.Set("offset", fmt.Sprintf("%d", v))
	}
	if v, _ := cmd.Flags().GetString("project"); v != "" {
		project, err := resolveProjectID(ctx, client, v)
		if err != nil {
			return err
		}
		params.Set("project_id", project.ID)
	}
	if mdFlags, _ := cmd.Flags().GetStringSlice("metadata"); len(mdFlags) > 0 {
		filter, err := buildMetadataFilterQueryParam(mdFlags)
		if err != nil {
			return err

View on GitHub (pinned to 2c0912b6ec)

Solutions

  1. Read the wrapped error — it distinguishes 'not found', 'ambiguous', and transport failures.
  2. List the workspace actors first (e.g. `multica` member/agent list command) and use the exact name or switch to --assignee-id with the concrete ID.
  3. For ambiguous names, use --assignee-id to disambiguate.
  4. If the wrapped error is a network/auth failure, verify connectivity and credentials, then retry.

Example fix

# before
multica issue list --assignee "Jon"
# after (ambiguous/typo -> use exact ID)
multica member list   # find the id
multica issue list --assignee-id usr_123456
Defensive patterns

Strategy: validation

Validate before calling

# verify the assignee exists before the list call
multica member list --output json | jq -e --arg n "$ASSIGNEE" 'any(.members[]; .name == $n or .id == $n)' >/dev/null \
  || { echo "unknown assignee: $ASSIGNEE" >&2; exit 1; }

Prevention

When it happens

Trigger: Running `multica issue list --assignee <name>` where <name> matches no user/agent in the workspace, matches several actors so the choice is ambiguous, or the resolution HTTP call errored. Using --assignee-id with a malformed/unknown ID can also surface here.

Common situations: Typo'd or display-name-vs-username mismatches; former team members no longer in the workspace; agents and users sharing a display name; transient API failures during the pre-list lookup.

Related errors


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