Troubleshooting Silent Table List Failures in Live Models (dbt and External Schema Tools) [Linux]

Users working with Live data models may report that a specific schema or database suddenly stops displaying available tables when browsing the schema. The API request (list_table_schemas) returns HTTP 200, but with an empty payload. This often occurs when external tools like dbt recreate tables or views in the data warehouse (e.g., BigQuery, Snowflake, Redshift), leaving Sisense’s metadata in a corrupted or stale state. -One or more schemas stop displaying any tables in the Sisense data model editor. -This affects a specific model, while other models using the same connection may work fine. -Exporting the .smodel file of the affected model shows inflated size compared to working models. -Duplicating the broken model preserves the issue. -Creating a new model from scratch using the same connection and data works normally.

Step-by-Step Guide:

Identify the Issue:

Check the HAR for the list_table_schemas call – it returns 200 but with no data.
Compare the .smodel file size of the broken model vs. a working test model. A significantly larger size is a red flag.
Review the .smodel file structure:

In working models, column metadata appears only under datasets > schema > tables > columns.
In broken models, columns may also incorrectly appear under a bloated relations array.

Resolution Steps:

Export the broken model and examine the structure.
If safe, attempt a manual cleanup:

Remove the relations array entirely if it contains duplicate or unstructured column metadata.
Reimport the model using the same name to trigger the "overwrite" behavior.

Alternatively, duplicate the model and delete all tables one by one.

Once all tables are removed, re-add them from scratch. The table list should now repopulate correctly.

If schema browsing is restored, recreate relationships manually as needed.

Conclusion:

Silent schema browsing failures in Sisense Live models are often metadata corruption issues caused by external tools (like dbt) modifying objects during active modeling. These cases leave no error in the UI but can be diagnosed by analyzing the model structure and isolating corrupted references. Rebuilding the model with fresh table definitions resolves the issue.

Best Practices to Prevent This Issue:

Avoid refreshing or editing Sisense models while dbt or CI/CD jobs actively deploy view or schema changes.
If using dbt, consider adding a delay before refreshing models in Sisense.
Educate end users about the impact of external schema rebuilds on live models.

Additional Note: While this article focuses on Live models, schema mismatches caused by tools like dbt can also affect ElastiCube models, typically surfacing during schema refresh or at build time.

However, Live models are more sensitive to upstream schema changes, because:

Sisense queries metadata (e.g., table lists) dynamically and instantly.
Live models can be refreshed frequently without performance concerns, exposing schema mismatches right away.

In contrast, ElastiCubes rely on cached schema definitions and often run on less frequent build schedules (to preserve server resources), which can delay or obscure detection of similar issues.