multica-ai/multica · error

Team issue scope is not supported by the Table query

Error message

Team issue scope is not supported by the Table query

What it means

Thrown by the scope-mapping switch in use-issue-surface-controller.ts: the UI can represent a 'team' issue scope (issues related to a team), but the Table query API only accepts 'my' and 'actor' scope kinds. Selecting a team scope while the Table surface is active hits the unmapped case and throws. It is a capability gap between the scope model and the table query contract, not a data error.

Source

Thrown at packages/views/issues/surface/use-issue-surface-controller.ts:413

          project_id: scope.projectId,
          ...(assigneeTypes ? { assignee_types: assigneeTypes } : {}),
        };
        break;
      }
      case "my":
        queryScope = {
          kind: "my",
          relation: scope.relation === "all" ? "any" : scope.relation,
        };
        break;
      case "actor":
        queryScope = {
          kind: scope.relation === "assigned" ? "assignee" : "creator",
          actor: { type: scope.actorType, id: scope.actorId },
        };
        break;
      case "team":
        throw new Error("Team issue scope is not supported by the Table query");
    }

    const date =
      dateParams.date_field && dateParams.date_start && dateParams.date_end
        ? {
            field: dateParams.date_field,
            start: dateParams.date_start,
            end: dateParams.date_end,
          }
        : undefined;
    return {
      scope: queryScope,
      filters: {
        ...(statusFilters.length > 0 ? { statuses: statusFilters } : {}),
        ...(priorityFilters.length > 0 ? { priorities: priorityFilters } : {}),
        ...(assigneeFilters.length > 0 ? { assignees: assigneeFilters } : {}),
        ...(includeNoAssignee ? { include_no_assignee: true } : {}),
        ...(creatorFilters.length > 0 ? { creators: creatorFilters } : {}),

View on GitHub (pinned to 2c0912b6ec)

Solutions

  1. Change the view scope away from team before using the Table surface (immediate user workaround).
  2. If you own the code: gate the team scope picker option (or map it to a supported equivalent such as actor scope with the team's actor id) when the active surface is the table.
  3. Longer term: extend the Table query scope contract on the server to accept kind 'team', then remove the throw.
  4. Audit saved views/deep links for team scopes that can land on the table surface and normalize them on load.

Example fix

// before
case "team":
  throw new Error("Team issue scope is not supported by the Table query");

// after — fall back to a supported scope so the table renders
case "team":
  queryScope = { kind: "my", relation: "any" };
  break;
Defensive patterns

Strategy: validation

Validate before calling

// Before switching to / rendering the Table surface
canQueryTable(scope) ? renderTable() : clampScopeToSupported(scope);

Type guard

function isTableQueryableScope(scope: IssueScope): boolean {
  return scope.kind !== "team";
}

Prevention

When it happens

Trigger: User picks a team-filtered view that renders through the Table query (e.g. switching surface from board/list to table while a team scope is active, or a saved view with team scope loaded in the table surface); any code path that calls the table query builder with scope.kind === 'team'.

Common situations: Saved views created in another surface that includes team scope; new team-scope UI shipped before table query support; deep links carrying a team scope param into the table surface.

Related errors


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