Do not close the connection when the error does not indicate that the connection is broken.
- Dominant language
- Go
- Stars
- 14.3k
- Forks
- 1.1k
- Avg merge
- 6d 9h
- Merged PRs (30d)
- 11
Description
**Is your feature request related to a problem? Please describe.**
Let's say the following code in the package `stdlib`
```go
func (c *Conn) Ping(ctx context.Context) error {
if c.conn.IsClosed() {
return driver.ErrBadConn
}
err := c.conn.Ping(ctx)
if err != nil {
// A Ping failure implies some sort of fatal state. The connection is almost certainly already closed by the
// failure, but manually close it just to be sure.
c.Close()
return driver.ErrBadConn
}
return nil
}
```
The connection will be closed in case of an error returned by `c.conn.Ping`, however not all errors are meant to be the connection is in a fatal state. For instance, the error `conn busy` is caused by using the same connection concurrently, but the connection is workable when the locker is released
**Describe the solution you'd like**
Check the error type to determine the close operation is necessary
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
**Additional context**
Add any other context or screenshots about the feature request here.
Contributor guide
Research direction
Start in the stdlib package at Conn.Ping and trace how errors returned by c.conn.Ping are handled. Check the existing error types and connection-close behavior; done means non-fatal errors such as conn busy no longer close an otherwise usable connection, while fatal errors still do.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, postgresql
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100