Apache Iceberg's Rust REST client reaches 13 of 25 catalog operations in a seven-catalog test

The limit on this client is set in its own source, before any catalog answers. According to the test's author, iceberg-catalog-rest builds eight URLs in total, in catalog.rs lines 177 to 215, and none of them is a view, a scan plan, a metrics report or a transaction ^[8]. That covers 11 of the 12 endpoints it cannot reach: all seven view operations, scan planning, metrics reporting, the separate credentials endpoint and commitTransaction ^[7][16]. No catalog configuration changes that list, because the client never forms those requests ^[8].

The twelfth gap is a stub. Catalog::update_namespace exists, returns "Updating namespace not supported yet!" at catalog.rs:659, and sends nothing ^[9]. The message is at least honest. The failure happens inside the client, so a permissions change on the catalog side will not fix it ^[9].

Two of the 13 counted operations work only in part. load_table cannot ask for ?snapshots=all, and list_namespaces pages internally and never sends pageSize ^[10]. The client does reach registerTable, which falls outside the 25 operations the suite covers ^[11].

The counting holds up. The suite is 33 checks covering 25 of the 35 operations in the Iceberg REST specification ^[5]. Five of those checks hit the same update_table endpoint, so a per-probe count gives 19 of 33 ^[6]. The author reports 13 of 25, or 52% ^[15]. I think the per-endpoint count is the right unit, since a per-probe figure mostly measures how many probes the suite aimed at one endpoint ^[6]. Each check is tied to a file and line in the client's published source, and a script, check_refs.py, confirms all 25 of those lines still sit inside the function they name ^[12]. I'd copy that step for any conformance claim about a library that keeps moving. Versions are pinned with "=0.10.1", so every result applies to one release ^[14].

The login result needs more care than the operation count. The client logs in to five of the seven catalogs, and on each of those, all 13 operations answer ^[3]. The two failures are AWS Glue and S3 Tables ^[4]. That leaves Polaris, BigLake, OneLake, Databricks Unity and Snowflake Horizon as the five. The author lists Unity and Horizon as not run ^[2]. On the evidence in the write-up, three of the five logins were exercised against a live catalog ^[17].

Reaching the five also takes two Cargo.toml lines beyond the client ^[13]. One pulls reqwest 0.12 with default features off and rustls-tls on. The other pulls iceberg-storage-opendal with the opendal-gcs and opendal-azdls features. Together they add a TLS backend and the cloud storage backends ^[13].

AWS is a separate problem. Glue and S3 Tables require a signature this client cannot produce, and the author says the Rust answer is two more catalog crates that do not implement quite the same operations ^[4]. A Rust tool that must serve AWS users ends up coding against a second crate with its own operation set ^[4].

For these numbers to transfer to another tool, three conditions have to hold. The tool pins 0.10.1 ^[14]. Its catalog is Polaris, BigLake or OneLake, or someone has run the suite against Unity or Horizon ^[17]. It needs none of the 12 missing operations. That rules out any tool that works with Iceberg views or calls commitTransaction ^[7].