[BUG] tables schema command fails to extract schema from Delta tables with checkpoint files

Bug Description

The fab tables schema command fails to return the schema for Delta tables that have checkpoint files (.checkpoint.parquet). The command either returns no output or raises a "ailed to extract the table schema. Please ensure the path points to a valid Delta table.

Root cause: The current implementation manually parses _delta_log JSON commit files via the OneLake API and searches for a metaData entry containing the schemaString. Delta Lake regularly compacts older commit log files into binary Parquet checkpoint files, after which the metaData entry is no longer present in the remaining JSON logs. The code only processes .json files and completely ignores .checkpoint.parquet files, making it unable to read schema information for any table that has been checkpointed.

fabric-cli version

1.6.1

Python version

3.13.9

Operating System

Windows

CLI Mode

Interactive mode

Authentication Method

Interactive browser login

Steps to Reproduce

1. Connect to a Lakehouse workspace that contains a Delta table that meets both of the following conditions:
   • The table has been written to enough times that Delta Lake has created at least one checkpoint file (.checkpoint.parquet in _delta_log/) - typically after 10+ transactions.
   • The pre-checkpoint JSON commit log files have been cleaned up (e.g., via VACUUM or Delta Lake's automatic log retention), so the metaData entry no longer exists in any of the remaining .json log files.
2. Run: fab tables schema /.Lakehouse/Tables/<table_name>
3. Observe the error or missing output.

Expected Behavior

The command should display the full schema of the Delta table, regardless of whether the schema is stored in JSON commit log files or in Parquet checkpoint files.

Actual Behavior

x table schema: [InvalidDeltaTable] Failed to extract the table schema. Please ensure the path points to a valid Delta table

Additional Context

Additionally, there is a typo in fab_constant.py ERROR_INVALID_DETLA_TABLE should be ERROR_INVALID_DELTA_TABLE.

Possible Solution

The issue affects all Delta tables that have undergone Delta Lake log compaction (checkpoint creation), which is a standard and expected behaviour for any table with more than ~10 transaction log entries.
The manual delta log parsing approach is also fragile with respect to schema evolution - it may return an outdated schema if log entries are spread across checkpoints and JSON files.
A possible fix is to use the deltalake Python library, which correctly handles both JSON logs and Parquet checkpoints and exposes schema via DeltaTable(...).schema(). This requires adding deltalake>=0.18.0 to the project dependencies.