I’ve been thinking more about this, and I believe that RCK cannot be our source of truth. I discovered the problem through RCK because Lakekeeper uses Rust, and when I looked into each Iceberg implementation, I saw that they all return different messages. However, this only happened because Lakekeeper was built with the Iceberg Rust implementation. If it had been built with Java, we wouldn’t have seen this problem. Another consideration is that we may never have a catalog implementation in every language, and I don’t think it makes sense to rely on third-party catalog implementations to guarantee the contract.
So I’m going back to my original position that error code + message as a contract is the better solution. On Tue, Aug 19, 2025 at 22:40, André Luis Anastácio <[ndrl...@proton.me.INVALID](mailto:On Tue, Aug 19, 2025 at 22:40, André Luis Anastácio <<a href=)> wrote: > 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 < [rdb...@gmail.com](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 >> <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? >>>>>> >>>>>> - >>>>>> 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
