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? >> >> >> 1. >> >> https://github.com/apache/iceberg/blob/fa80ba787af776f516e772f27bf746756de93b70/core/src/main/java/org/apache/iceberg/UpdateRequirement.java#L186 >> 2. >> >> https://github.com/apache/iceberg-rust/blob/e7160df4a0cb8f2f6ce12681053e8cb1a43b74e1/crates/iceberg/src/catalog/mod.rs#L711 >> 3. >> >> https://github.com/apache/iceberg-python/blob/main/pyiceberg/table/update/__init__.py#L801 >> 4. >> >> https://github.com/apache/iceberg-go/blob/b4babc8b919258be7b25f5cc295fc68a458f9559/table/requirements.go#L268 >> >> >> >> André Anastácio >> >
