Are error codes really the right solution? What user sees an error code and thinks "great, that's something I can use to solve my problem!"
If we are going to standardize user-facing errors, then I think the right thing to do is to standardize the error message. That's helpful to humans. The error type is already specified by the spec and is a readable name that can be used in place of an error code for clients that want to handle errors that don't get shown to users. That's also something you can test against if you don't want to use the standard error messages. To me, introducing error codes is not helpful and just adds complication. On Tue, Aug 19, 2025 at 1:02 PM André Luis Anastácio <ndrl...@proton.me.invalid> wrote: > 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? >>> >>> >>> 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 >>> >> >
