Race condition: create_table returns success before table is available

[kriszyp]

Problem

create_table (via the operations API) returns a success response before the table is fully initialized and available for subsequent operations. Downstream calls made immediately after creation fail as if the table does not exist — even with 2-second sleep guards in tests.

Observed in CI runs (GitHub Actions) across multiple runs.

Symptoms

• Test calls create_table → receives success response
• Test (optionally sleeps 2s) → calls insert or queries the table
• Failure: table not found / does not exist

Likely cause

The ITC-based schema sync path acknowledges the schema event synchronously on receipt and runs the actual schema handler in the background (see commit 59dec882). This means the API response can be sent before the worker threads have fully propagated the new table schema. If a subsequent operation lands on a worker that hasn't yet processed the background handler, the table appears absent.

Steps to reproduce

Flaky; occurs under CI load. Integration test: 16_terminologyUpdates.js L52 in the operations API test suite.

🤖 Filed by Claude on behalf of Kris.

[heskew]

A schema-visibility-across-workers instance of this race, on the per-device-type DB sharding path (test added in #1195). Integration Tests 3/6 (Node.js v22), blob.test.mjs:512 & :552:

AssertionError: doorlock schema missing
  describe_all returned: {"thermostat":{...},"sensor":{...},"doorlock":{}}
HdbError: Table 'doorlock.DoorlockBlob' does not exist

DoorlockBlob is created and Initialized on http/3 (Initialized table "DoorlockBlob", schema: doorlock) but describe_all and a SQL query on [main/0] don't yet see it — the new table is acknowledged before it has propagated to all workers / the catalog describe_all reads, exactly the "returns success before the table is available" failure mode. Re-run went green. Evidence: PR #1371 run 27734341245 / job 82048056876 (attempt 1). (Related: #1358.)

(Filed by Claude / Opus 4.8 during CI flake triage.)