Are joins within the same cluster consistent and isolated in Azure Data Explore?

I was not able to find any documentation for Azure Data Explorer on which ACID guarantees are provided, and in what circumstances.

Supposes there is a Kusto query:

PackageVersions
| where LowerId = "newtonsoft.json"
| join kind=inner PackageDownloads on Identity

Also, suppose there is a table swap operation that happens while this query is executing:

.rename tables
    PackageVersions_OLD = PackageVersions,
    PackageVersions = PackageVersions_NEW,
    PackageDownloads_OLD = PackageDownloads,
    PackageDownloads = PackageDownloads_NEW

Will the first (read) query run in an isolated way such that the rename operation logically happens only BEFORE or AFTER the read?

Or is it possible for the read query to see intermediate states like PackageVersions missing (after the first rename) or old PackageDownloads data and new PackageVersions data (after the second rename)?

And if these two queries (read and write) are atomic inside the same Azure Data Explorer database, do these guarantees extend to queries across multiple databases in the same cluster or even queries across multiple clusters?

Solution

a query runs on an snapshot of a database which includes all tables and other child entities. if a certain entity (e.g., a table) gets modified (e.g., renamed) after a query took the aforementioned snapshot when it started its execution - that modification does not affect the snapshot used by the in-progress query.

is it possible for the read query to see intermediate states like PackageVersions missing (after the first rename) or old PackageDownloads data and new PackageVersions data (after the second rename)?

the rename operation is atomic, i.e. all of its parts are committed as a single transaction, and there are no "intermediate" states that are readable.

And if these two queries (read and write) are atomic inside the same Azure Data Explorer database, do these guarantees extend to queries across multiple databases in the same cluster or even queries across multiple clusters?

everything written above refers to the database scope. when you run a cross-database (or cross-cluster) query - each of the database participating in the query has the same concepts mentioned above applied to it individually. there are no cross-database/cross-cluster transactional guarantees for write operations (and there are also no cross-database/cross-cluster write transactions that are supported by the service).