[
https://issues.apache.org/jira/browse/CASSGO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
João Reis updated CASSGO-113:
-----------------------------
Description:
h2. Problem
ErrCodeOverloaded (0x1001) and ErrCodeBootstrapping (0x1002) are currently
parsed as generic errorFrame instances.
This prevents applications from handling these error conditions in a
type-safe way, forcing them to rely on error message inspection or
error code matching.
h2. Use Case
Some applications and wrapper libraries need to distinguish these server
error conditions in a type-safe way, for example to implement custom
retry, backoff, observability, or request classification logic.
At the moment, ErrCodeOverloaded and ErrCodeBootstrapping are exposed as
generic errorFrame values, which makes them inconsistent with other
server errors that already have dedicated request error types.
h2. Proposal
Introduce dedicated error types:
- RequestErrOverloaded
- RequestErrBootstrapping
These should follow the same pattern as existing error types such as:
- RequestErrUnavailable
- RequestErrWriteTimeout
- RequestErrReadTimeout
Edit by [~joaoreis]: After some discussion it was decided to add error types
for more error codes (all of them except Protocol and Server, because the
driver internally depends on these so it will require more changes)
was:
h2. Problem
ErrCodeOverloaded (0x1001) and ErrCodeBootstrapping (0x1002) are currently
parsed as generic errorFrame instances.
This prevents applications from handling these error conditions in a
type-safe way, forcing them to rely on error message inspection or
error code matching.
h2. Use Case
Some applications and wrapper libraries need to distinguish these server
error conditions in a type-safe way, for example to implement custom
retry, backoff, observability, or request classification logic.
At the moment, ErrCodeOverloaded and ErrCodeBootstrapping are exposed as
generic errorFrame values, which makes them inconsistent with other
server errors that already have dedicated request error types.
h2. Proposal
Introduce dedicated error types:
- RequestErrOverloaded
- RequestErrBootstrapping
These should follow the same pattern as existing error types such as:
- RequestErrUnavailable
- RequestErrWriteTimeout
- RequestErrReadTimeout
> Add dedicated error types for more errors
> -----------------------------------------
>
> Key: CASSGO-113
> URL: https://issues.apache.org/jira/browse/CASSGO-113
> Project: Apache Cassandra Go driver
> Issue Type: Improvement
> Components: Core
> Reporter: Paolo Elefante
> Priority: Normal
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> h2. Problem
> ErrCodeOverloaded (0x1001) and ErrCodeBootstrapping (0x1002) are currently
> parsed as generic errorFrame instances.
> This prevents applications from handling these error conditions in a
> type-safe way, forcing them to rely on error message inspection or
> error code matching.
> h2. Use Case
> Some applications and wrapper libraries need to distinguish these server
> error conditions in a type-safe way, for example to implement custom
> retry, backoff, observability, or request classification logic.
> At the moment, ErrCodeOverloaded and ErrCodeBootstrapping are exposed as
> generic errorFrame values, which makes them inconsistent with other
> server errors that already have dedicated request error types.
> h2. Proposal
> Introduce dedicated error types:
> - RequestErrOverloaded
> - RequestErrBootstrapping
> These should follow the same pattern as existing error types such as:
> - RequestErrUnavailable
> - RequestErrWriteTimeout
> - RequestErrReadTimeout
> Edit by [~joaoreis]: After some discussion it was decided to add error types
> for more error codes (all of them except Protocol and Server, because the
> driver internally depends on these so it will require more changes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
