clockworklabs/SpacetimeDB · error

Failed to read value from the `{}` column of `{}` for table_

Error message

Failed to read value from the `{}` column of `{}` for table_id `{}`

What it means

While collecting row-level-security rules, SchemaViewer::rls_rules_for_table read the sql column of st_row_level_security but the AlgebraicValue was not a string (into_string() failed). A row exists for the table_id, yet the column value's type does not match the String layout the reader expects.

Source

Thrown at crates/engine/src/sql/ast.rs:62

    fn rls_rules_for_table(&self, table_id: TableId) -> anyhow::Result<Vec<Box<str>>> {
        self.tx
            .iter_by_col_eq(
                ST_ROW_LEVEL_SECURITY_ID,
                StRowLevelSecurityFields::TableId,
                &AlgebraicValue::from(table_id),
            )?
            .map(|row| {
                row.read_col::<AlgebraicValue>(StRowLevelSecurityFields::Sql)
                    .with_context(|| {
                        format!(
                            "Failed to read value from the `{}` column of `{}` for table_id `{}`",
                            "sql", "st_row_level_security", table_id
                        )
                    })
                    .and_then(|sql| {
                        sql.into_string().map_err(|_| {
                            anyhow::anyhow!(format!(
                                "Failed to read value from the `{}` column of `{}` for table_id `{}`",
                                "sql", "st_row_level_security", table_id
                            ))
                        })
                    })
            })
            .collect::<anyhow::Result<_>>()
    }
}

impl<'a, T> SchemaViewer<'a, T> {
    pub fn new(tx: &'a T, auth: &'a AuthCtx) -> Self {
        Self { tx, auth }
    }
}

View on GitHub (pinned to 6dee26c6ef)

Solutions

1. Inspect the st_row_level_security rows for the table_id named in the message and check the actual type of the sql column
2. If the database predates a system-table layout change, recreate or migrate it with the current version
3. Never write to st_* system tables directly; go through the engine's DDL/RLS APIs

match viewer.rls_rules_for_table(table_id) {
    Ok(rules) => rules,
    Err(e) if e.to_string().contains("st_row_level_security") => {
        // system-table layout drift or corruption: surface with table_id context
        log::error!("rls metadata unreadable for table {table_id}: {e:#}");
        return Err(e);
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: SQL query planning invoking rls_rules_for_table on a table whose st_row_level_security row's Sql column holds a non-string value; system-table layout drift after a version upgrade; st_row_level_security rows written by anything other than the current engine version.

Common situations: Opening a database created by an older SpacetimeDB version whose st_row_level_security schema differs; corrupted system table pages; manual or out-of-band writes into st_* system tables.

Related errors

• `table_id` must not be `TableId::SENTINEL` in `{row_level_se
• Index '${indexLabel}' on table '${tableLabel}' must define a
• When replaying `st_column` update: `table_primary_key` shoul
• When replaying `st_column` update: `table_type` should not h
• Invalid system variable {s}

AI-assisted analysis of clockworklabs/SpacetimeDB@6dee26c6ef (2026-08-20). Data as JSON: /api/errors/3a15828f0cd8a9af. Report an issue: GitHub.