fix: Misleading error messages in iceberg-catalog-rest and allow StatusCode::OK in responses#962
Merged
Xuanwo merged 1 commit intoapache:mainfrom Feb 11, 2025
Merged
Conversation
connortsui20
changed the title
iceberg-catalog-rest and allow StatusCode::OK in responsesiceberg-catalog-rest and allow StatusCode::OK in responses
Xuanwo
approved these changes
Feb 11, 2025
Member
Xuanwo
left a comment
Xuanwo
left a comment
There was a problem hiding this comment.
Thank you @connortsui20, I love this change.
Contributor
Author
|
Ok so it turns out this introduces a bug where |
Contributor
Author
|
@Xuanwo just a heads up my change introduced a bug because I was unaware of the endpoint responses: https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml I am working right now on a fix that will hopefully consolidate the 3 types of request functions in Every single endpoint has exactly 1 "OK" case except |
Xuanwo
pushed a commit
that referenced
this pull request
Mar 10, 2025
Followup of #962 #962 Introduced a bug where it is not some of the methods allow for both `StatusCode::OK` and `StatusCode::NO_CONTENT` as success cases, when in reality it should be one or the other (this was me, sorry about that). This PR attempts to unify the 3 different types of response helpers that essentially all do the exact same thing slightly differently. The main addition here is a function `query_catalog`: ```rust // Queries the Iceberg REST catalog with the given `Request` and a provided handler. pub async fn query_catalog<R, H, Fut>(&self, mut request: Request, handler: H) -> Result<R> where R: DeserializeOwned, H: FnOnce(Response) -> Fut, Fut: Future<Output = Result<R>>, { self.authenticate(&mut request).await?; let response = self.client.execute(request).await?; handler(response).await } ``` By allowing each `Catalog` method to specify how they want to handle the responses, it gets much finer control on the success/error cases as well as the error messages. Previously, there were 3 functions that all did similar things: ```rust pub async fn query<R: DeserializeOwned, E: DeserializeOwned + Into<Error>>( &self, mut request: Request, ) -> Result<R> { pub async fn execute<E: DeserializeOwned + Into<Error>>( &self, mut request: Request, ) -> Result<()> { pub async fn do_execute<R, E: DeserializeOwned + Into<Error>>( &self, mut request: Request, handler: impl FnOnce(&Response) -> Option<R>, ) -> Result<R> { ``` I'm also somewhat using this as a chance to refactor some other parts of this crate, mainly documentation and examples. @Xuanwo It would be great if I could get feedback on some of these proposed changes before I keep going!
ZENOTME
pushed a commit
to risingwavelabs/iceberg-rust
that referenced
this pull request
Mar 12, 2025
Followup of apache#962 apache#962 Introduced a bug where it is not some of the methods allow for both `StatusCode::OK` and `StatusCode::NO_CONTENT` as success cases, when in reality it should be one or the other (this was me, sorry about that). This PR attempts to unify the 3 different types of response helpers that essentially all do the exact same thing slightly differently. The main addition here is a function `query_catalog`: ```rust // Queries the Iceberg REST catalog with the given `Request` and a provided handler. pub async fn query_catalog<R, H, Fut>(&self, mut request: Request, handler: H) -> Result<R> where R: DeserializeOwned, H: FnOnce(Response) -> Fut, Fut: Future<Output = Result<R>>, { self.authenticate(&mut request).await?; let response = self.client.execute(request).await?; handler(response).await } ``` By allowing each `Catalog` method to specify how they want to handle the responses, it gets much finer control on the success/error cases as well as the error messages. Previously, there were 3 functions that all did similar things: ```rust pub async fn query<R: DeserializeOwned, E: DeserializeOwned + Into<Error>>( &self, mut request: Request, ) -> Result<R> { pub async fn execute<E: DeserializeOwned + Into<Error>>( &self, mut request: Request, ) -> Result<()> { pub async fn do_execute<R, E: DeserializeOwned + Into<Error>>( &self, mut request: Request, handler: impl FnOnce(&Response) -> Option<R>, ) -> Result<R> { ``` I'm also somewhat using this as a chance to refactor some other parts of this crate, mainly documentation and examples. @Xuanwo It would be great if I could get feedback on some of these proposed changes before I keep going!
ZENOTME
pushed a commit
to risingwavelabs/iceberg-rust
that referenced
this pull request
Mar 20, 2025
Followup of apache#962 apache#962 Introduced a bug where it is not some of the methods allow for both `StatusCode::OK` and `StatusCode::NO_CONTENT` as success cases, when in reality it should be one or the other (this was me, sorry about that). This PR attempts to unify the 3 different types of response helpers that essentially all do the exact same thing slightly differently. The main addition here is a function `query_catalog`: ```rust // Queries the Iceberg REST catalog with the given `Request` and a provided handler. pub async fn query_catalog<R, H, Fut>(&self, mut request: Request, handler: H) -> Result<R> where R: DeserializeOwned, H: FnOnce(Response) -> Fut, Fut: Future<Output = Result<R>>, { self.authenticate(&mut request).await?; let response = self.client.execute(request).await?; handler(response).await } ``` By allowing each `Catalog` method to specify how they want to handle the responses, it gets much finer control on the success/error cases as well as the error messages. Previously, there were 3 functions that all did similar things: ```rust pub async fn query<R: DeserializeOwned, E: DeserializeOwned + Into<Error>>( &self, mut request: Request, ) -> Result<R> { pub async fn execute<E: DeserializeOwned + Into<Error>>( &self, mut request: Request, ) -> Result<()> { pub async fn do_execute<R, E: DeserializeOwned + Into<Error>>( &self, mut request: Request, handler: impl FnOnce(&Response) -> Option<R>, ) -> Result<R> { ``` I'm also somewhat using this as a chance to refactor some other parts of this crate, mainly documentation and examples. @Xuanwo It would be great if I could get feedback on some of these proposed changes before I keep going!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Several of the error messages in
iceberg-catalog-resthad misleading error messages, so this PR fixes some of those.Additionally, several of the
Catalogmethods onRestCatalogdo not acceptStatusCode::OKas a successful response, so I've added that in as well. This meant that some of theclient.rsfunctions had to change, but given that they are only used so many times I thought it was fine to remove the const generics.There are also a few other things that could be cleaned up but I'll keep this PR short.