You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems not very rust idiomatic for a SDK like ours to accept timeouts, which is why we've not added them. Retries are supported internally in the SDK, we just don't currently expose any retry strategies in the public API. Are you looking for the ability to set retry strategies or do you want access to what the retries were via an error? Typically we'd expect the operation future to just be dropped by the application which would mean we couldn't return an error at all.
Hi why will you say it is not rust idiomatic to accept timeouts? Timeouts are core part of any API.
As for retries if you don't have timeouts below your retry later, then how can you even retry when there is a timeout. Today with using your sdk we added timeout in our couchbase wrapper and it times out after 2.5s, but we have no way to use your retry logic, we will need to build our own retry logic on top of the our timeout logic.
As for retries if you don't have timeouts below your retry later, then how can you even retry when there is a timeout
I'm unsure I follow you here. No Couchbase SDKs will ever retry on a timeout, they all return an error when a timeout occurs. The Rust SDK works like other SDKs with regards to retries - it will, when applicable, retry until the operation future is dropped.
So maybe then my understanding is wrong, java and go sdk don't retry when there is a kv timeout? If not then it is fine. I have ever only worked with rust sdk so not sure how it works with other sdks
Activity
chvck commentedon Oct 30, 2025
Hi @ankurmittal what are you looking to do here?
It seems not very rust idiomatic for a SDK like ours to accept timeouts, which is why we've not added them. Retries are supported internally in the SDK, we just don't currently expose any retry strategies in the public API. Are you looking for the ability to set retry strategies or do you want access to what the retries were via an error? Typically we'd expect the operation future to just be dropped by the application which would mean we couldn't return an error at all.
ankurmittal commentedon Oct 30, 2025
Hi why will you say it is not rust idiomatic to accept timeouts? Timeouts are core part of any API.
As for retries if you don't have timeouts below your retry later, then how can you even retry when there is a timeout. Today with using your sdk we added timeout in our couchbase wrapper and it times out after 2.5s, but we have no way to use your retry logic, we will need to build our own retry logic on top of the our timeout logic.
chvck commentedon Oct 30, 2025
I'm unsure I follow you here. No Couchbase SDKs will ever retry on a timeout, they all return an error when a timeout occurs. The Rust SDK works like other SDKs with regards to retries - it will, when applicable, retry until the operation future is dropped.
ankurmittal commentedon Oct 30, 2025
So maybe then my understanding is wrong, java and go sdk don't retry when there is a kv timeout? If not then it is fine. I have ever only worked with rust sdk so not sure how it works with other sdks
chvck commentedon Oct 30, 2025
That's correct - if you're interested you can read our retry RFC at https://github.com/couchbaselabs/sdk-rfcs/blob/master/rfc/0049-sdk3-retry-handling.md. Once there's a timeout we stop retrying the operation in all SDKs.