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

Jump to bottom

database/sql: Stmt.Close() seem to ignore the error #37973

Closed
Serhii1011010 opened this issue Mar 20, 2020 · 5 comments
Closed

database/sql: Stmt.Close() seem to ignore the error #37973

Serhii1011010 opened this issue Mar 20, 2020 · 5 comments
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@Serhii1011010
Copy link

What version of Go are you using (go version)?

$ go version

go version go1.14.1 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env

GO111MODULE=""

GOARCH="amd64"

GOBIN=""

GOCACHE="/home/user/.cache/go-build"

GOENV="/home/user/.config/go/env"

GOEXE=""

GOFLAGS=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

GOINSECURE=""

GONOPROXY=""

GONOSUMDB=""

GOOS="linux"

GOPATH="/home/user/go"

GOPRIVATE=""

GOPROXY="https://proxy.golang.org,direct"

GOROOT="/usr/local/go"

GOSUMDB="sum.golang.org"

GOTMPDIR=""

GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"

GCCGO="gccgo"

AR="ar"

CC="gcc"

CXX="g++"

CGO_ENABLED="1"

GOMOD="/home/user/tmp/go_example1/go.mod"

CGO_CFLAGS="-g -O2"

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS="-g -O2"

PKG_CONFIG="pkg-config"

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build865698656=/tmp/go-build -gno-record-gcc-switches"

What did you do?

run this code https://play.golang.org/p/hiITqzSJ5O4

package main

import (
	"github.com/DATA-DOG/go-sqlmock"

	"database/sql"
	"database/sql/driver"
	"fmt"
)

func doSQL(connection *sql.DB) error {
	statement, err := connection.Prepare("INSERT INTO something (column) VALUES($1)")
	if err != nil {
		return err
	}

	defer func() {
		err := statement.Close()
		if err != nil {
			panic(err)
		}
	}()

	_, err = statement.Exec("")
	return err
}

func main() {
	connection, mock, err := sqlmock.New()
	if err != nil {
		panic(err)
	}
	defer connection.Close()

	mock.ExpectPrepare("INSERT").
		WillBeClosed().
		WillReturnCloseError(fmt.Errorf("close error")).
		ExpectExec().
		WillReturnResult(driver.ResultNoRows)

	if err := doSQL(connection); err != nil {
		panic(err)
	}

	// we make sure that all expectations were met
	if err := mock.ExpectationsWereMet(); err != nil {
		panic(err)
	}
}

What did you expect to see?

panic because of error

What did you see instead?

nothing

Comments

It seems that the issue is not in go-sqlmock, but in go because I run the debugger and found this function https://github.com/golang/go/blob/master/src/database/sql/sql.go#L2701 being called and it returns nil and ignores error in v.ds.closeErr
@odeke-em odeke-em changed the title sql Stmt.Close() seem to ignore the error database/sql: Stmt.Close() seem to ignore the error Mar 21, 2020
@odeke-em odeke-em added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 21, 2020
@odeke-em
Copy link
Member

Thank you for reporting this bug @Sergey1011010 and welcome to the Go project!

Kindly paging @kardianos to take a look.

@Serhii1011010 Serhii1011010 mentioned this issue Mar 21, 2020
Merged
@kardianos
Copy link
Contributor

@Sergey1011010 Thanks for the report.

  1. Can you please provide a report without using sqlmock?
  2. A sql.Stmt is actually a Stmt pool. It will only actually close the stmt pool if there are no stmt dependencies that need to leave it open.
  3. In your example, you call doSQL(connection *sql.DB) error. I'm concerned with your naming, your concept might be incorrect. a *sql.DB isn't a connection, but a connection pool with zero or more connections held in it. Similarly, a *sql.Stmt may be prepared on one or more connections.
  4. If you want to see a stmt error on close, first call *db.Conn(ctx), then call Prepare on the connection (not the pool), then you could close the connection, then close the stmt, in that order (I think).

A better design I think would be to separate out the Stmt from the stmt pool concept. But that would be impossible util a sql/v2.

@kardianos kardianos added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 21, 2020
@Serhii1011010
Copy link
Author

@kardianos, many thanks for the explanation. If I use not pool, but real connection, the error does happen.

Can you please provide a report without using sqlmock?

Not sure how to make a real driver produce an error on Close statement.

@kardianos
Copy link
Contributor

I think I can consider this a limitation of the current design, that may be worked around by using an explicit Conn. If you agree, please close.

@ALTree
Copy link
Member

ALTree commented Jun 18, 2021

OP probably agrees, I guess. Anyway no news for about a year, I think we can archive this.

@ALTree ALTree closed this as completed Jun 18, 2021
@golang golang locked and limited conversation to collaborators Jun 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@kardianos @ALTree @odeke-em @gopherbot @Serhii1011010