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

Merged
merged 1 commit into from
Oct 18, 2024

Conversation

Al2Klimov
Copy link
Member

@Al2Klimov Al2Klimov commented Aug 8, 2024

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

closes 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!

retry/retry.go Outdated Show resolved Hide resolved
Some errors created within github.com/lib/pq are created with
fmt.Errorf, prefixed with "pq: ". Thus, they are not of the *pq.Error
type, but are clearly database errors.

A change request was created upstream in:
lib/pq#1169

Co-Authored-By: Alvar Penning <[email protected]>
@yhabteab yhabteab removed the request for review from julianbrost October 18, 2024 08:20
@yhabteab yhabteab merged commit 77a5457 into main Oct 18, 2024
15 checks passed
@yhabteab yhabteab deleted the expected-ReadyForQuery-620 branch October 18, 2024 08:21
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.

Icinga DB crashes when it can't reach the PostgreSQL database
5 participants