cube-js/cube · error

The '${query.action}' action type doesn't supported.

Error message

The '${query.action}' action type doesn't supported.

What it means

The pre-aggregations jobs endpoint supports exactly two actions: 'post' (queue build jobs) and 'get' (poll job status by tokens). Any other value of `query.action` reaches the switch's `default` branch. Note this is a plain `Error`, not a `UserError` — a quirk, since it is really a client mistake — and it surfaces as an internal-style error response.

Source

Thrown at packages/cubejs-api-gateway/src/gateway.ts:1091

            context,
            <PreAggsSelector>value.selector
          );
          if (result.length === 0) {
            throw new UserError(
              'A user\'s selector doesn\'t match any of the ' +
              'pre-aggregations defined in the data model.'
            );
          }
          break;
        case 'get':
          result = await this.preAggregationsJobsGET(
            context,
            <string[]>query.tokens,
            query.resType,
          );
          break;
        default:
          throw new Error(`The '${query.action}' action type doesn't supported.`);
      }
      this.event(`pre_aggregations_jobs_${query.action}`, {
        source: req.header('source') || 'unknown',
      });
      response(result, { status: 200 });
    } catch (e: any) {
      this.handleError({ e, context, query, res: response, requestStarted });
    }
  }

  /**
   * Post pre-aggregations build jobs entry point.
   */
  private async preAggregationsJobsPOST(
    context: RequestContext,
    selector: PreAggsSelector,
  ): Promise<string[]> {
    let jobs: string[] = [];

View on GitHub (pinned to 7d981676b3)

Solutions

  1. Set `action` to exactly 'post' (queue builds) or 'get' (poll by `tokens`) — lowercase.
  2. If you wanted to trigger a build, use `action: 'post'` with a `selector`; if you wanted status, use `action: 'get'` with `tokens` returned from a previous post.
  3. Check your Cube version's gateway code/docs: the accepted action set is defined by the `switch` in `preAggregationsJobs` and the Joi schema.
  4. If you believe a new action should be supported, it is not — use the pre-aggregations build/preview HTTP endpoints or the orchestration API instead.

Example fix

// before
{ "action": "BUILD", "selector": { "cubes": ["Events"] } }

// after
{ "action": "post", "selector": { "cubes": ["Events"], "timezones": ["UTC"] } }
Defensive patterns

Strategy: type-guard

Validate before calling

const VALID_ACTIONS = ['post', 'get'];
function assertValidAction(body) {
  if (!VALID_ACTIONS.includes(body?.action)) {
    throw new Error(`action must be one of ${VALID_ACTIONS.join(', ')}; got ${body?.action}`);
  }
}

Type guard

function hasSupportedAction(q: unknown): q is { action: 'post' | 'get' } {
  return !!q && typeof q === 'object' &&
    ((q as any).action === 'post' || (q as any).action === 'get');
}

Try / catch

try {
  const res = await postPreAggJobs(payload);
} catch (e) {
  if (String(e.message).includes("action type doesn't supported")) {
    console.error(`Unsupported action "${payload.action}"; use 'post' or 'get'`);
  }
}

Prevention

When it happens

Trigger: POSTing to `/cubejs-system/v1/pre-aggregations/jobs` with an `action` value other than 'post' or 'get' (e.g., 'build', 'refresh', 'POST', 'Post', or a missing action that somehow passed earlier checks). Note: an absent/invalid action usually fails Joi validation first (error 5), so this branch fires mainly when the schema permits the value but the switch doesn't handle it.

Common situations: Migrating scripts written against older Cube APIs or docs that used different action names; case-sensitivity mistakes ('POST' vs 'post'); typos like 'post jobs' or 'build'; copying endpoint examples from other Cube endpoints (e.g., the pre-aggregations preview API) into the jobs endpoint.

Related errors


AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02). Data as JSON: /api/errors/65fc328b0878d16a. Report an issue: GitHub.