You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Version 0.0.485 (July 24, 2026)
Power BI "Reload tables" and OBO sign-in drop from minutes to seconds on large tenants — on a delegated (Entra/OBO) Power BI connection, every Reload crawled the whole tenant twice (once to refresh the shared catalog, then the identical crawl again for the caller's per-user overlay), and each crawl re-introspected every semantic model with a per-dataset COLUMNSTATISTICS() query — a path rate-limited to ~120 executeQueries/user/min, so a 350-model tenant paid several minutes per click, twice over. The overlay sync now reuses the catalog the shared refresh just fetched with the same user's token (identity-matched, never borrowed across users), and discovery is incremental: the identity-scoped dataset listing (~3s even at 500 models) decides what the caller can see, known datasets are rebuilt from the indexed catalog, and only new datasets pay the introspection cost — with dataset renames propagated from the listing, vanished datasets dropped, and previously-unreadable models retried live. Creation-time, scheduled, and background reindexing keep full introspection so column-level drift in known models is still detected. Measured live against a real Entra tenant with 500 programmatically created semantic models: one Reload click went from 8m50s (1,010 executeQueries) → 4.9s (4 executeQueries); adding a single new model costs 6.3s with exactly that model introspected. The same reuse path speeds up the post-sign-in overlay sync, and the plumbing (prior_tables) is generic so other catalog-crawling connectors (e.g. Tableau) can opt in.
Power BI schemas no longer leak the internal RowNumber-<GUID> column — COLUMNSTATISTICS() returns the hidden Vertipaq row-number column for every table; it was indexed as a real column, rendered into the agent's schema context, and referenced in generated DAX, which the engine rejects ("cannot be found or may not be used in this expression" — seen in production against the built-in Usage Metrics Report model). The column is now filtered at discovery time (both the COLUMNSTATISTICS fallback and the admin-scan parser), and the DAX guide warns the agent never to reference RowNumber-* columns (covering schemas indexed before this fix) and to wrap bare column references in an aggregation inside SUMMARIZECOLUMNS/ADDCOLUMNS/ROW expression slots — the two exact failures observed.