What causes "assignee only supports = operator" in gastownhall/beads?

Use `assignee = ` for exact match, or `assignee = none` (also "null" or empty) for unassigned issues.

assignee only supports = operator

Error message

assignee only supports = operator

What it means

The assignee field supports only exact equality (=). applyAssigneeFilter rejects !=, ordering, and all other operators because IssueFilter models assignment as a single exact-match Assignee string (plus a NoAssignee flag), with no exclude or range semantics. Using = with "none"/"null"/empty is interpreted as the special no-assignee filter.

Source

Thrown at internal/query/evaluator.go:277

	return nil
}

func (e *Evaluator) applyTypeFilter(comp *ComparisonNode, filter *types.IssueFilter) error {
	if comp.Op != OpEquals && comp.Op != OpNotEquals {
		return fmt.Errorf("type only supports = and != operators")
	}
	issueType := types.IssueType(strings.ToLower(comp.Value))
	if comp.Op == OpEquals {
		filter.IssueType = &issueType
	} else {
		filter.ExcludeTypes = append(filter.ExcludeTypes, issueType)
	}
	return nil
}

func (e *Evaluator) applyAssigneeFilter(comp *ComparisonNode, filter *types.IssueFilter) error {
	if comp.Op != OpEquals {
		return fmt.Errorf("assignee only supports = operator")
	}
	if comp.Value == "" || strings.ToLower(comp.Value) == "none" || strings.ToLower(comp.Value) == "null" {
		filter.NoAssignee = true
	} else {
		filter.Assignee = &comp.Value
	}
	return nil
}

func (e *Evaluator) applyOwnerFilter(comp *ComparisonNode, filter *types.IssueFilter) error {
	// Owner filtering requires predicate
	return fmt.Errorf("owner filtering requires predicate mode")
}

func (e *Evaluator) applyLabelFilter(comp *ComparisonNode, filter *types.IssueFilter) error {
	if comp.Op != OpEquals {
		return fmt.Errorf("label only supports = operator")
	}

View on GitHub (pinned to 71377f2769)

Solutions

Use `assignee = <name>` for exact match, or `assignee = none` (also "null" or empty) for unassigned issues.
For exclusion, filter client-side: query broadly and drop issues whose Assignee equals the excluded value in code.
For multiple assignees, run one query per assignee and merge results.

Example fix

// before (find unassigned)
"assignee != alice"
// after
"assignee = none"  // unassigned; or filter alice out client-side

Defensive patterns

Strategy: validation

Validate before calling

func validateAssigneeComp(op query.Op) error {
    if op != query.OpEquals {
        return fmt.Errorf("assignee supports only =; use assignee = none for unassigned")
    }
    return nil
}

Try / catch

if err := e.applyComparison(comp, filter); err != nil {
    if strings.Contains(err.Error(), "assignee only supports") {
        return fetchAndFilterClientSide(func(i types.Issue) bool { return i.Assignee != excluded })
    }
    return err
}

Prevention

Use assignee = none (or null/empty) to find unassigned issues instead of !=.
Handle exclusions and multi-assignee logic client-side after an exact-match query.
Keep a per-field operator capability table in query-building code.

When it happens

Trigger: Queries like `assignee != alice`, `assignee > bob`, `assignee ~ carol` — Field="assignee" with any Op other than OpEquals.

Common situations: Users who used `status != closed` or `type != bug` (both allowed) assuming != works everywhere; wanting "unassigned" via `assignee != something` instead of `assignee = none`.

Related errors

AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30). Data as JSON: /api/errors/7ac539be434243ee. Report an issue: GitHub.