I started a proposal document focused on standardizing requirement errors. I believe this will solve most of the problems, and then we can evolve to handle other cases.
https://docs.google.com/document/d/136ed1dhktQvWGc1u_-3CPR5-beqRqvEgTqJ5MoBFP8Q/edit?usp=sharing André Anastácio On Wednesday, August 13th, 2025 at 11:33 AM, Steve Loughran <ste...@cloudera.com.INVALID> wrote: > not error messages ` too brittle, maintenance mess. > > some hex error code for each failure which your tests can assert on and which > can be documented in a table is a much better design. Windows does this > -based on the design of DEC's VMS OS > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/18d8fbe8-a967-4f1c-ae50-99ca8e491d2d > > On Mon, 11 Aug 2025 at 18:29, Daniel Weeks <dwe...@apache.org> wrote: > >> Hey André, >> >> The RCK suite uses the catalog tests from reference implementation to ensure >> consistency across implementations. Your point is valid that as the other >> languages started to build client/server implementations that didn't have >> the exact same messaging. >> >> I think we want to push toward some amount of standardization in the error >> messages. Ideally we'd steer away from anything language specific, but we >> want the messaging to be clear and consistent for things like what caused a >> requirement to fail. >> >> I think that the solution might be a combination of what you've identified. >> Possibly relaxing or clarifying some of the messaging but also leaving room >> so that requirements aren't overly strict. Also, I think we're open to just >> better/more consistent messaging because we didn't focus too much on it when >> building the java tests. Having the other language clients use the RCK would >> also help drive consistency. >> >> If there are specific examples, we might want to start with a couple >> failures and see what makes sense as a solution. >> >> -Dan >> >> On Tue, Aug 5, 2025 at 8:14 AM André Luis Anastácio >> <ndrl...@proton.me.invalid> wrote: >> >>> Hello everyone, >>> >>> When I was running the RCK against Lakekeeper, I noticed that RCK verifies >>> not only the exception type but also the error message. RCK verifies the >>> messages as they are written in the Java implementation, and since >>> Lakekeeper uses iceberg-rust, we have different error messages [1] Java [2] >>> Rust. However, the error messages are written differently in other clients >>> as well [3] Python [4] Go. >>> >>> This could become a broader compatibility issue as we see more REST >>> implementations built on different language foundations. >>> >>> Should we standardize the error messages across all implementations, make >>> RCK more permissive by focusing only on exception types, or handle this at >>> the REST server implementation level where each implementation adapts to >>> match RCK expectations? >>> >>> Are there other solutions I haven't considered? >>> >>> - >>> https://github.com/apache/iceberg/blob/fa80ba787af776f516e772f27bf746756de93b70/core/src/main/java/org/apache/iceberg/UpdateRequirement.java#L186 >>> - >>> https://github.com/apache/iceberg-rust/blob/e7160df4a0cb8f2f6ce12681053e8cb1a43b74e1/crates/iceberg/src/catalog/mod.rs#L711 >>> - >>> https://github.com/apache/iceberg-python/blob/main/pyiceberg/table/update/__init__.py#L801 >>> - >>> https://github.com/apache/iceberg-go/blob/b4babc8b919258be7b25f5cc295fc68a458f9559/table/requirements.go#L268 >>> >>> André Anastácio
