DeltaLake.Table fails on Usage Metrics semantic model because _delta_log contains URL-encoded parque

carlol 

You are requesed to verify these things, this will confirm that what is causing this behaviour   

• Confirm the problem occurs in a newly created Usage Metrics semantic model.
• Verify the same behavior from another workspace or tenant.
• Check whether normal Lakehouse Delta tables (created by notebooks or Dataflows) continue to work.
• Compare the latest _delta_log_entry entries with the physical filenames to confirm the encoding mismatch.

Possible temporary replacements are:

Export the Usage Metrics data through another supported interface (Power BI REST APIs or Admin APIs where applicable).

Or possible wait for a Fabric service fix.

Recommendation:

If you could share the complete error message (ErrorCode = 10061).

A sample showing the mismatch between:

_delta_log entry:


If this helps, ✓ Mark as Kudos | Help Others

This looks less like a query issue and more like a potential regression in how DeltaLake.Table is resolving file names.

Based on what you've described:

AzureStorage.DataLake can successfully enumerate the folders, parquet files, and _delta_log.

The Delta log references URL-encoded file names (%28 and %29), while the storage connector returns decoded names (( and )).

The failure occurs consistently across multiple Usage Metrics tables, suggesting it's not isolated to a single table.

If this started without any changes on your side and previously worked, it does point toward a recent change in either the Fabric runtime or the Delta connector.

A few things worth checking:

Confirm the issue reproduces in a new query and in a different workspace to rule out corruption.

Test another Delta table that doesn't contain parentheses or other special characters in the parquet file names.

Verify whether the same behavior occurs from a Notebook or Spark, which can help determine whether the issue is specific to Power Query's DeltaLake.Table implementation.

Since this appears to affect multiple Usage Metrics semantic model tables and the storage itself is accessible, I'd recommend opening a Microsoft support ticket with a minimal repro. The mismatch between URL-encoded paths in _delta_log and decoded paths returned by AzureStorage.DataLake could indicate a regression that Microsoft will need to investigate.

Hi User,

Based on your description, this appears to be a service-side regression rather than an issue with your M query.

The key observation is that:

• AzureStorage.DataLake() returns the physical file names with decoded characters, for example:

  Users-..._(215434)...parquet

• The corresponding entries in _delta_log reference the same files using URL-encoded names:

  Users-..._%28215434%29...parquet

• DeltaLake.Table() then fails with ErrorCode 10061 because it cannot resolve the file referenced in the Delta log.

Since this was working previously and now fails across multiple Usage Metrics tables, it suggests there may have been a recent change in how OneLake or DeltaLake.Table() handles URL-encoded file paths.

A few things I'd recommend:

• Verify whether the issue reproduces with a newly created Usage Metrics semantic model or only existing ones.

• Test from another workspace or tenant (if available) to determine whether the issue is environment-specific.

• Compare the _delta_log entries with the physical file names to confirm the mismatch is consistent across all affected tables.

• Check the Microsoft Fabric Known Issues page and Service Health dashboard for any recently reported Delta Lake or OneLake regressions.

• Since this appears to be a platform issue, collect the Activity ID, Request ID, timestamp, and a sample of the encoded vs. decoded filenames, then open a Microsoft Support ticket. This will help the engineering team reproduce the issue.

For more information:

• DeltaLake.Table connector: https://learn.microsoft.com/power-query/connectors/deltalake

• OneLake documentation: https://learn.microsoft.com/fabric/onelake/onelake-overview

• Microsoft Fabric known issues: https://learn.microsoft.com/fabric/get-started/known-issues

Could you also clarify:

• Does the issue occur only with Usage Metrics semantic models, or with other Delta tables stored in OneLake as well?

• Have there been any recent Fabric or Power BI updates in your environment before the issue started?

• Does the failure occur in both Power BI Desktop and Power Query Online, or only in one environment?

These details will help determine whether this is a broader OneLake/Delta regression or something specific to Usage Metrics semantic models.

Hi carlol ,

Thanks for reaching out to fabric community.

Could you please review the solution provided above and let us know if you have any further questions.

Thanks!!

Hi carlol ,

Thank you for confirming the root cause and work around which helped you in resolving the issue. This will help other community members who are facing similar issue to get resolved faster.

Please accept your own solution as answer.

Thanks!!