Ryan, thank you for your input. My initial thought regarding the error code was that since the error type for requirements will always be a CommitFailedException, the error type alone isn't sufficient for this case. However, I'm fine with following the message standardization approach. My concern is that RCK will define the standard rather than something external like a contract.
What's most complicated for me here is defining the standardization in the OpenAPI definition, which adds a lot of boilerplate for something that could be a simple JSON file with error codes and messages (like Delta does [1]). Apart from the error code, do you have any thoughts about including the requirement type in the message to make it clearer? 1 - https://github.com/delta-io/delta/blob/364b9ec100e22bbe41e8a56658269bd0c8a49bca/spark/src/main/resources/error/delta-error-classes.json André Anastácio On Tue, Aug 19, 2025 at 21:12, Ryan Blue <[[email protected]](mailto:On Tue, Aug 19, 2025 at 21:12, Ryan Blue <<a href=)> wrote: > 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 > <[email protected]> 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 >> <[email protected]> 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 < [email protected]> 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 >>>> <[email protected]> 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
