search

trinodb / trino-go-client

Go client for Trino
Apache License 2.0
131 stars 60 forks source link

Expose underlying trino error codes / names #97

Closed deigote closed 5 months ago

deigote commented 10 months ago

ATM the only visible attribute on error is the http status code (from ErrQueryFailed), but a client might want to react differently depending on the underlying trino error (for example, if it's a exceeded time limit the error might bubble up, whereas if it's an exceeded cpu limit it could back off and retry). Right now the information is avail in the stmtError, but that's not exported.

chenzeshenga commented 10 months ago

same feature required, thanks in advance

ornew commented 5 months ago

I agree with this issue.

However, I don't think #98 is a fundamental solution. To capture a broader range of use cases, I believe we should provide a way for users to obtain details about the errors.

The first issue is that stmtError is not exported and cannot be Unwrap. When a stmtError occurs, it is set as the Reason for ErrQueryFailed, but since it cannot be Unwrap, users are unable to retrieve the details. ErrQueryFailed should be made Unwrap-able, and stmtError should be exported. Unwrap would also allow for the identification of errors during transport layers.

Another issue is the omission of fields that may be necessary for precise problem identification. stmtError and stmtFailureInfo may include stack information and multiple causes. We should define the missing fields and ensure detailed information is decoded.

These changes would allow for the propagation of information to users through the error values and make it possible to identify errors. Adding information to error messages would be also enabled by these changes.