nil-pointer dereference in getConn
Have no idea how to handle or investigate this panic.
runtime.errorString: runtime error: invalid memory address or nil pointer dereference
File "/builds/tt/snami/snami/v2/interfaces/rest/middleware/sentry.go", line 158, in recoverWithSentry
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 80, in (*baseDB).getConn
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 136, in (*baseDB).withConn
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 245, in (*baseDB).exec
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 220, in (*baseDB).ExecContext
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 119, in (*baseDB).initConn
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 84, in (*baseDB).getConn
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 136, in (*baseDB).withConn
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 315, in (*baseDB).query
File "/builds/tt/snami/snami/.cache/go/pkg/mod/github.com/go-pg/pg/[email protected]/base.go", line 290, in (*baseDB).QueryContext
Seems like nil conection returned from the pool, but have no idea how it's possible
It looks like there is a code path that might allow both the err and the connection to be nil.
https://github.com/go-pg/pg/blob/e8d0e95cbd9239859683c3b932c520616000edb1/internal/pool/pool.go#L172-L174
If there are more dial errors than the "pool size" then it will return the last dial error.
https://github.com/go-pg/pg/blob/e8d0e95cbd9239859683c3b932c520616000edb1/internal/pool/pool.go#L215-L220
But if the last dial error is nil for whatever reason, then this function could return nil, nil causing such a panic.
Looking at this, this seems to be the only way that you could get a nil connection without an error path. But I don't see an immediate way that that error could be nil under those circumstances.
Found a conn.Execute in onConnect handler in legacy code. May be this thing can lead to the nil conn in case of full pool?
Reproduced only on prod, so trying to reproduce it locally first with no luck yet.