What causes "invalid worker type: {ty}" in risingwavelabs/risingwave?

Use a valid WorkerType numeric value in the dashboard path (check the `WorkerType` protobuf enum for the discriminants, e.g. Frontend/Compute/Compactor).

risingwavelabs/risingwave · warning · DashboardError

invalid worker type

Error message

invalid worker type: {ty}

What it means

The dashboard's `list_clusters` HTTP handler converts the path parameter `ty` (an i32) into a `WorkerType` via `TryFrom`. If the conversion fails or yields `Unspecified`, the handler responds with "invalid worker type: {ty}" — the requested numeric worker type is not a valid enum value.

Solutions

Use a valid WorkerType numeric value in the dashboard path (check the `WorkerType` protobuf enum for the discriminants, e.g. Frontend/Compute/Compactor).
Omit/adjust the filter to list all workers if you don't need to filter by type.
Fix automation/scripts that hardcode worker type codes after a protobuf enum change, and align client and server versions.
Validate the `ty` value client-side against the WorkerType enum before calling the endpoint.

Example fix

// before
GET /api/clusters/0   // Unspecified -> rejected
// after
GET /api/clusters/1   // e.g. Frontend

Defensive patterns

Strategy: validation

Validate before calling

// Client-side: only send valid WorkerType discriminants
fn is_valid_worker_type(ty: i32) -> bool {
    matches!(ty, 1..=6) // per WorkerType proto; excludes 0 = Unspecified
}

Try / catch

const res = await fetch(`/api/clusters/${ty}`);
if (res.status === 500) { // dashboard maps anyhow errors to 500
  throw new Error(`worker type ${ty} invalid; use a valid WorkerType value`);
}

Prevention

Derive dashboard URLs from the WorkerType protobuf enum instead of hardcoding numbers
Never pass 0 (Unspecified) or negative values as the worker type filter
Keep client tooling and server versions aligned when the WorkerType enum changes

When it happens

Trigger: GET to the dashboard `/clusters/:ty` endpoint with a path segment that is not one of the defined WorkerType discriminants (e.g. 0, negative numbers, or IDs for types removed in newer versions).

Common situations: Hand-typed dashboard URLs or scripts using the wrong enum number; version skew where a client uses a WorkerType value the running meta doesn't define; typos in monitoring configurations referencing worker type codes.

Understand the failure class

Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.

Related errors

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/c12c6d2748fae82e. Report an issue: GitHub.

Appendix: source

Thrown at src/meta/src/dashboard/mod.rs:154

    impl IntoResponse for DashboardError {
        fn into_response(self) -> axum::response::Response {
            let mut resp = Json(json!({
                "error": self.0.to_report_string(),
            }))
            .into_response();
            *resp.status_mut() = StatusCode::INTERNAL_SERVER_ERROR;
            resp
        }
    }

    pub async fn list_clusters(
        Path(ty): Path<i32>,
        Extension(srv): Extension<Service>,
    ) -> Result<Json<Vec<WorkerNode>>> {
        let worker_type = match WorkerType::try_from(ty) {
            Ok(WorkerType::Unspecified) | Err(_) => {
                return Err(err(anyhow!("invalid worker type: {ty}")));
            }
            Ok(worker_type) => worker_type,
        };
        let mut result = srv
            .metadata_manager
            .list_worker_node(Some(worker_type), None)
            .await
            .map_err(err)?;
        result.sort_unstable_by_key(|n| n.id);
        Ok(result.into())
    }

    async fn list_table_catalogs_inner(
        metadata_manager: &MetadataManager,
        hummock_manager: &HummockManagerRef,
        table_type: TableType,
    ) -> Result<Json<Vec<TableWithStats>>> {
        let tables = metadata_manager

View on GitHub (pinned to 6469eb736d)