Hey Alex, I took a look at the PR. Typically, validations happen as part of *update requirements *(*UpdateRequirements *is the main class), which are executed and checked before any *updates* are applied on the commit path in *CatalogHandlers*. I don't think the scenario described in the PR is reproducible in the Java reference implementation when using Table / View APIs because we have code in *TableMetadata* & *ViewMetadata* that assigns a new schema ID when schemas differ. It would be good to understand how exactly the Terraform provider created those requirements & updates for the Table update request.
On Wed, Apr 29, 2026 at 7:38 PM Alex Stephen via dev <[email protected]> wrote: > Hello, > > The Iceberg Terraform provider > <http://github.com/apache/iceberg-terraform>uncovered the fact that the > REST Fixture does not validate any id values (schema-id, field-id, > last-partition-id, etc) for duplication. This is one of many validations > the Fixture can perform. > > I've raised a PR <https://github.com/apache/iceberg/pull/16148> to fix > this, but it's kicked off a conversation about the level of validation that > the REST Fixture should have. > > I propose that the REST Fixture should validate the inputs as much as > possible, especially since all of our implementations test against the > fixture. Adding validations to the fixture will ensure that we can catch > downstream errors in the implementations. > > Please take a look at the PR and I'd appreciate any community opinions > regarding the desired functionality level for the REST Fixture. > > Thanks, > > Alex Stephen >
