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 errView on GitHub (pinned to 2c0912b6ec)
Solutions
- Read the wrapped error — it distinguishes 'not found', 'ambiguous', and transport failures.
- 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.
- For ambiguous names, use --assignee-id to disambiguate.
- 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
- Prefer --assignee-id over --assignee in scripts — IDs are unambiguous and stable.
- Cache the actor list once per run instead of guessing display names.
- Read the wrapped error to distinguish not-found/ambiguous from network failure.
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
- no agent found matching %q
- ambiguous agent %q; matches: %s
- invalid --sort %q; valid values: %s
- invalid --direction %q; valid values: asc, desc
- --direction requires --sort to be one of %s; position (the d
AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15).
Data as JSON: /api/errors/6fbe73cfde036efb.
Report an issue: GitHub.