Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actually retry every database error, including "pq: ..." #59

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Al2Klimov
Copy link
Member

They aren't of type *pq.Error, but they're clearly database errors.

refs Icinga/icingadb#620
("fixes" will be a dependency update.)

@cla-bot cla-bot bot added the cla/signed CLA is signed by all contributors of a PR label Aug 8, 2024
@oxzi oxzi added this to the 0.3.2 milestone Aug 26, 2024
retry/retry.go Outdated
@@ -193,7 +194,7 @@ func Retryable(err error) bool {

var mye *mysql.MySQLError
var pqe *pq.Error
if errors.As(err, &mye) || errors.As(err, &pqe) {
if errors.As(err, &mye) || errors.As(err, &pqe) || strings.HasPrefix(err.Error(), "pq: ") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add a bit more information here? Does this case necessary belong to this if?

Personally, I am a bit puzzled by this change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I am a bit puzzled by this change.

According to Icinga/icingadb#620 (comment), lib/pq may return errors as non-helpful types. To me, that sounds more like an issue in lib/pq where this change is a workaround at best. This definitely isn't how best-practice error handling in Go should look like, so this should say why this is necessary. Is there a bug report in lib/pq on this error reporting that could be references for example?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I didn't found any: https://github.com/lib/pq/issues?q=is%3Aissue+is%3Aopen+errorf

Also, it's not the worst workaround IMAO, as /^pq: / catches them all at once.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This definitely isn't how best-practice error handling in Go should look like,

Not so loud, please! 🙈 https://github.com/Icinga/icingadb/blob/v1.2.0/pkg/icingaredis/utils.go#L96

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's just returning an error, not error handling. Should we have the need to handle that error specifically, that should be changed to its own type rather than checking for that string, that's all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@oxzi oxzi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While still being unhappy about how the error needs to be checked, the change looks good to me now.

@yhabteab
Copy link
Member

yhabteab commented Sep 6, 2024

Please rebase!

They aren't of type *pq.Error, but they're clearly database errors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla/signed CLA is signed by all contributors of a PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants