-
Notifications
You must be signed in to change notification settings - Fork 21
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
"operation was canceled" from net
not treated as context cancellation error
#473
Comments
Given that this is now included in released Go versions for a while (included from 1.19), this should not need any more work from our side. Our current release packages were built with a recent enough version (I checked only Icinga DB 1.1.0 ob Debian 10, that was built with Go 1.19.3, that version should be the same for all other distributions). |
Actually, the issue still isn't fixed yet. ~/Workspace/go/src/icinga-notifications (trigger-time-based-escalations ✗) go version
go version go1.20.4 darwin/arm64 When using unix sockets it still crashes immediately. 2023-05-24T16:47:22.433+0200 INFO icinga-notifications Connecting to database at '/run/postgresql'
2023-05-24T16:47:22.434+0200 WARN database Can't connect to database. Retrying {"error": "dial unix /run/postgresql/.s.PGSQL.5432: connect: no such file or directory"}
2023-05-24T16:47:22.434+0200 FATAL icinga-notifications cannot connect to database {"error": "can't connect to database: can't retry: dial unix .... But when using TCP it doesn't crash but keeps retrying: 2023-05-24T16:48:21.616+0200 INFO icinga-notifications Connecting to database at 'localhost:0'
2023-05-24T16:48:21.619+0200 WARN database Can't connect to database. Retrying {"error": "dial tcp [::1]:5432: connect: connection refused"}
2023-05-24T16:53:21.620+0200 FATAL icinga-notifications cannot connect to database {"error": "can't connect to database: can't retry: dial tcp [::1]:5432: connect: connection refused" |
NM! This is the wrong issue. |
When a network operation from the
net
packages fails withnet.errCanceled
, the returned errorerr
does not satisfyerrors.Is(err, context.Canceled)
which just resulted in a longer debugging session as this tore down errgroups because the error wasn't considered a context cancellation when it should be.Unfortunately, there doesn't seem to be a really good way of accessing that error object, so to check it, you probably have to resort to comparing the error string.
This behavior was recently changed in Go, but the change isn't included in any released version: golang/go@85b5f86
The text was updated successfully, but these errors were encountered: