Repository navigation
[BUG] tables schema command fails to extract schema from Delta tables with checkpoint files #228
Description
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
- 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.
- Run: fab tables schema /.Lakehouse/Tables/<table_name>
- 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.
Activity
microsoft-github-policy-service commentedon Apr 30, 2026
Thank you for submitting this issue, pkontek.
A member of the Fabric CLI team will review your submission and provide feedback shortly.
github-actions commentedon Apr 30, 2026
AI Assessment: Potential Bug
The described behavior is consistent with a limitation in the current implementation of the
fab tables schemacommand when applied to Delta tables that have undergone log compaction and checkpoint creation. Delta Lake's checkpointing replaces JSON commit logs with Parquet checkpoint files, which are not handled by manual log parsing. This results in schema extraction failures for tables with only checkpoint files present, as outlined in the report. This deviates from expected CLI behavior, since schema retrieval should work for all valid Delta tables, regardless of log retention status. The suggested fix of using thedeltalakePython library aligns with best practices for robust schema extraction and compatibility.The issue affects table usability and could hinder workflows involving schema operation on Delta tables with normal transaction histories. Severity is elevated because it blocks basic schema inspection for large or long-lived Delta tables, which are common scenarios.
The additional typo in
fab_constant.py(ERROR_INVALID_DETLA_TABLE) is valid but minor.Next Steps
🔔 Escalated to team — This issue requires team review and has been flagged for attention.
github-actions commentedon Apr 30, 2026
🔔 @microsoft/fabric-cli-dev — This issue has been flagged by AI triage as requiring team attention. Please review the assessment above.
test: add checkpoint regression test for issue microsoft#228
ayeshurun commentedon Jun 24, 2026
Verdict: Likely fabric-cli bug — confirmed in code.
fab tables schemaonly parses_delta_logJSON commits and ignores Parquet checkpoints, so schema extraction fails once themetaDataentry has been compacted into a.checkpoint.parquetand the originating JSON logs are removed.Evidence
src/fabric_cli/commands/tables/fab_tables_schema.py_get_commit_logs(L46–54) filters the OneLake listing to.jsonfiles only (if f.endswith(".json"));.checkpoint.parquetfiles are never collected._extract_schema_from_commit_logs(L58–80) walks those JSON logs and returnsmetadata["schemaString"]from the firstmetaDataentry (L73–78). If no remaining JSON log containsmetaData(post-checkpoint + log cleanup), it returnsNone.exec_command(L17–28) then raisesInvalidDeltaTable"Failed to extract the table schema..." — exactly the reported error.src/fabric_cli/core/fab_constant.pyL267 definesERROR_INVALID_DETLA_TABLE("DETLA" → "DELTA"), referenced atfab_tables_schema.pyL27.Suggested next step: Read schema from the latest Delta checkpoint as well as JSON commits (e.g. parse the newest
*.checkpoint.parquet, or adopt thedeltalakelibrary'sDeltaTable(...).schema()as the author suggests) so checkpointed tables resolve; and fix theERROR_INVALID_DETLA_TABLEtypo.Automated triage by Microsoft Scout — please verify before acting.