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

[johannesvuorinen]

We hit a runtime bug in the JS spacetimedb package (2.0.4) that breaks published databases with existing snake_case schemas.

Symptom

• spacetime publish succeeds
• the new instance then fatally crashes on first reducer call
• subsequent CLI calls fail with 403 / The instance encountered a fatal error
• logs show panics like Uncaught No such index

What we observed

It looks like internal runtime index/source names are being derived from JS accessor keys instead of canonical table/column names.

Example:

• table accessor: cardDetails
• field/accessor: nameKey
• runtime expected:
  • cardDetails_nameKey_idx_btree
• actual published DB index name:
  • card_details_name_key_idx_btree

Another example:

• runtime expected:
  • runtimeIslandStates_ownerId_idx_btree
• actual DB index name:
  • runtime_island_states_owner_id_idx_btree

So the runtime looks up a non-existent index and panics.

Why we think this is the cause

We patched the installed runtime in node_modules/spacetimedb/dist/server/index.mjs with these two changes:

1. Use canonical column names when building the index column list

colNameList.push(row.row[elem.name]?.columnMetadata?.name ?? elem.name);

instead of:

colNameList.push(elem.name);

2. Use canonical table name instead of accessor name when building index source names

const sourceName = index.sourceName = `${tableName}_${colS}_idx_${index.algorithm.tag.toLowerCase()}`;

instead of:

const sourceName = index.sourceName = `${accName}_${colS}_idx_${index.algorithm.tag.toLowerCase()}`;

After that patch:

- reducer calls stopped panicking
- config reducers like set_storage_config worked again
- runtime smoke tests passed on both staging and live published databases

## Environment

- spacetimedb CLI/runtime version 2.0.4

## Expected behavior

Runtime index/source-name resolution should be based on canonical schema names, not JS accessor identifiers.

[Shubham8287]

Are you publishing to main-cloud Or using standalone version (please provide version if this is the case)?

[Shubham8287]

Is it happening just after you migrated from 1.x to 2.x?

[reilly-freret]

@Shubham8287 running into this as well (2.3.0). happy to help troubleshoot or provide more info.

[Shubham8287]

Hi @reilly-freret , would it be possible for you to share how you’re defining the table and index?

I’m particularly interested in seeing the accessor names, and also the canonical names if you’re providing them explicitly.

Are you seeing this error while migrating a module from 1.x to 2.x?

[reilly-freret]

sure. for context, we are observing the same exact symptoms that johannes reported in the original issue, but we haven't been able to come up with a minimal reproduction specific to indexes or index names. here's the timeline of the first fatal bug yesterday:

1. we add three new columns to the targetableProperties_v1 table

export const targetableProperties_v1 = withusTable(
  { accessor: "targetable_properties_v1", public: false },
  {
    id: targetablePropertyId.primaryKey().autoInc(),
    canonicalAddress: Addresses.canonicalAddressSpacetimeSchema,
    googlePlaceId: t.string().index("btree"),
    googlePlacePhotoName: t.string().optional(),
    // new columns; should be valid per https://spacetimedb.com/docs/databases/automatic-migrations/
    latitude: t.number().optional().default(undefined),
    longitude: t.number().optional().default(undefined),
    sqft: t.number().optional().default(undefined),
  },
);

2. our CI pipeline publishes the changes to our staging env in maincloud -- everything succeeds, albeit warnings about client disconnection (this made sense; some views changed)

3. we notice errors in our observability platforms in onConnect

4. we check the spacetimedb maincloud dashboard and notice `Failed to fetch row count" on every table in the staging db

5. we panic

6. we destroy the staging database and republish with the following table def

export const targetableProperties_v1 = withusTable(
  { accessor: "targetable_properties_v1", public: false },
  {
    id: targetablePropertyId.primaryKey().autoInc(),
    canonicalAddress: Addresses.canonicalAddressSpacetimeSchema,
    googlePlaceId: t.string().index("btree"),
    googlePlacePhotoName: t.string().optional(),
  },
);

// brand new table with "manual" migration reducer to lift any existing _v1 rows up to _v2
export const targetableProperties_v2 = withusTable(
  { accessor: "targetable_properties_v2", public: false },
  {
    id: targetablePropertyId.primaryKey().autoInc(),
    canonicalAddress: Addresses.canonicalAddressSpacetimeSchema,
    googlePlaceId: t.string().index("btree"),
    googlePlacePhotoName: t.string().optional(),
    latitude: t.number().optional().default(undefined),
    longitude: t.number().optional().default(undefined),
    sqft: t.number().optional().default(undefined),
  },
);

7. symptoms are gone, staging is happy until today... we're observing the same symptoms after a publish that added an optional column (this time, with an index, which led us to this open issue) to an existing table - t.bool().default(false).index()

[Shubham8287]

Thank you so much, I am looking into this.

[Shubham8287]

@reilly-freret I am not yet able to reproduce this. I have couple of more questions:

1. What's the new column name that you are adding as t.bool().default(false).index() ?
2. Are you hitting a runtime error, when calling a reducer which uses new column index?

Update: nvm., I get to reproduce it now. Thank you.

[Shubham8287]

@reilly-freret I got the PR for this up, Are you block on this? Accordingly, I will communicate with the team for release.

Apologies for the trouble, and thank you for reporting it.

[reilly-freret]

@Shubham8287 thanks so much for the quick PR. we can currently work around the issue by performing a manual migration (using versioned tables), but we're nervous to push any schema changes to production before this is fixed.

it'd be a different story if this problem were caught during publish, but since publish can succeed while leaving the db in an unusable state, we prefer to wait until the PR is merged and released.