parquet status exception

Hi bubbledep, 

I have run into "ParquetStatusException" a few times in Fabric, especially right after writing tables from Dataflow Gen2. In most cases it has been stale or inconsistent metadata on the default semantic model, or a schema quirk introduced by a merged output. Here are the things that usually clear it up for me:

1. Quick reset of the default semantic model
   Open your Warehouse or Lakehouse, go to Reporting > Manage default semantic model, remove all tables, Confirm, then add them back and try again. Several folks have reported this resolves ParquetStatusException without any other changes: community thread.
2. Recheck the merged output’s schema
   Merges can quietly create duplicate or odd column names, mixed data types, or unsupported types that write fine but fail when read by Direct Lake. In your Dataflow Gen2 step that produces the merged table:
   • Make every column’s type explicit (no Any). Prefer text, whole number, fixed decimal, datetime, boolean.
   • Ensure every column name is unique and simple (no dots, slashes, or leading/trailing spaces).
   • Avoid very wide decimals or binary columns.
   If in doubt, write the four source tables again and do the merge in SQL as a Warehouse table or view to isolate the issue.
3. Force a clean table rewrite
   If the delta/parquet files got into a bad state during the previous write, create a brand-new output table name from the dataflow and point the semantic model at that fresh table. This often bypasses lingering file references that trigger the exception. Similar 404 BlobNotFound and parquet status cases have been reported and resolved with a fresh write: example report, another thread.
4. Keep Direct Lake expectations in mind
   Direct Lake reads physical tables from OneLake. Model tables sourced from views fall back to DirectQuery. If you are mixing modes, a problematic table can surface only when it is read via Direct Lake. More context here: Direct Lake notes and an overview of how Direct Lake reads delta/parquet under the hood: overview.
5. If it persists, capture details for support
   Grab the error time, workspace name, item ids, table name, and correlation id, and include the links above showing this as a known class of issue. That will help Support triage faster.

On the UI change you noticed: yes, the navigation has been updated recently, but the ParquetStatusException itself usually tracks back to metadata or file state, not the UI.

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.