Skip to content

Fix index schema from st tables.#5145

Open
Shubham8287 wants to merge 2 commits into
masterfrom
shub/fix-table-migration-index
Open

Fix index schema from st tables.#5145
Shubham8287 wants to merge 2 commits into
masterfrom
shub/fix-table-migration-index

Conversation

@Shubham8287
Copy link
Copy Markdown
Contributor

@Shubham8287 Shubham8287 commented May 29, 2026

Description of Changes

fixes #4701.

IndexSchema when build from system tables, wasn't considering st_index_accessor table to set alias.

Module use this alias in ABIs causing reducer's causing runtime panic like Uncaught No such index

API and ABI breaking changes

NA

Expected complexity level and risk

1

Testing

Added a smoketest for typescript, this is more apparent in typescript due to snake_case name casing results in different canonical and accessor name.

@Shubham8287 Shubham8287 changed the title Fix index. accessor entries on table migration Fix indexes alias on table migration May 29, 2026
@Shubham8287 Shubham8287 force-pushed the shub/fix-table-migration-index branch from 6191d7c to 7e41705 Compare May 29, 2026 13:51
@Shubham8287 Shubham8287 changed the title Fix indexes alias on table migration Fix indexe schema on restart. May 29, 2026
@Shubham8287 Shubham8287 changed the title Fix indexe schema on restart. Fix index schema from st tables. May 29, 2026
Comment on lines +209 to +211
index_schema.alias = self
.find_st_index_accessor_row_by_index_name(index_schema.index_name.as_ref())?
.map(|row| row.accessor_name);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This restores the persisted source_name alias when rebuilding IndexSchema, which fixes the restart/recreate path, but I think auto-migration still has the same issue. auto_migrate_indexes only compares accessor_name and algorithm, not IndexDef.source_name. If a TS module changes the generated source name while keeping the same canonical index name/accessor/algorithm, the migration can succeed without updating st_index_accessor, and the runtime will still call index_id_from_name with the new source name.

Should we reject source_name changes as requiring manual migration, or add a step to update st_index_accessor?

const TYPESCRIPT_MODULE_WITH_NEW_COLUMNS: &str = r#"import { schema, table, t } from "spacetimedb/server";

const users = table(
{ name: "users", public: false },
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make the table accessor differ from the canonical table name? The reported issue involved runtime/source index names being built from both table and column accessor names while the stored index used canonical snake_case names. This test covers column accessor divergence but not table accessor divergence because both names are currently users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JS runtime 2.0.4 derives internal index names from accessor keys instead of canonical schema names, causing "No such index" panics after publish

2 participants