Problem Statement
Currently, SDK users face friction when handling statement execution errors. Distinguishing between transient failures (retryable) and permanent failures requires brittle workaround logic, such as manually parsing the SQLSTATE code from raw error message strings. Users may also desire to have the SDK retry for them.
Proposed Solution
Improve developer experience by exposing structured error metadata directly on the statement execution response.
- Structured Attributes: Expose sqlstate as a distinct attribute, separating it from the human-readable message.
- Retry Guidance: Include an is_retryable boolean flag or an error_category enum to explicitly indicate if the operation should be retried.
- Alternative: Implement a configurable "auto-retry" mechanism within the SDK to handle transient errors transparently.
Problem Statement
Currently, SDK users face friction when handling statement execution errors. Distinguishing between transient failures (retryable) and permanent failures requires brittle workaround logic, such as manually parsing the SQLSTATE code from raw error message strings. Users may also desire to have the SDK retry for them.
Proposed Solution
Improve developer experience by exposing structured error metadata directly on the statement execution response.