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

database/sql: context cancellation allows statements to execute after rollback #34775

Closed
dadkins-at-dropbox opened this issue Oct 8, 2019 · 25 comments
Labels
Milestone

Comments

@dadkins-at-dropbox
Copy link

@dadkins-at-dropbox dadkins-at-dropbox commented Oct 8, 2019

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

1.12.8

Does this issue reproduce with the latest release?

I haven't been able to run with the latest version, but examination of the code shows that the problem is still there.

What did you do?

Very rarely, I have observed problems resulting from transactions rolled back as a result of context cancellation. Namely, I have observed writes from presumably aborted transactions persist nonetheless. I added enough debugging output to the mysql driver to observe the following sequence:

driver.Tx.Rollback()
driver.Stmt.ExecContext()
driver.Conn.Close()

What did you expect to see?

The driver documentation at https://golang.org/pkg/database/sql/driver/#ConnBeginTx:

    // If the context is canceled by the user the sql package will
    // call Tx.Rollback before discarding and closing the connection.

Furthermore, the documentation promises that driver connections won't be used concurrently by multiple goroutines:
Conn is a connection to a database. It is not used concurrently by multiple goroutines.

What did you see instead?

I believe that contract was violated and that there is a gap between the "rollback" and the "close" in which a statement was allowed to execute. Since MySQL defaults to autocommit, that statement which we thought was executing within a transaction (which got rolled back) actually executed outside the transaction and committed.

I believe the bug is in tx.rollback in sql.go:

// rollback aborts the transaction and optionally forces the pool to discard
// the connection.
func (tx *Tx) rollback(discardConn bool) error {
	if !atomic.CompareAndSwapInt32(&tx.done, 0, 1) {
		return ErrTxDone
	}
	var err error
	withLock(tx.dc, func() {
		err = tx.txi.Rollback()
	})
	if err != driver.ErrBadConn {
		tx.closePrepared()
	}
	if discardConn {
		err = driver.ErrBadConn
	}
	tx.close(err)
	return err
}

The connection is locked to call driver.Tx.Rollback(), but nothing prevents a statement from executing before we get to tx.close(err).

@dadkins-at-dropbox
Copy link
Author

@dadkins-at-dropbox dadkins-at-dropbox commented Oct 8, 2019

Standalone repro:
https://gist.github.com/dadkins-at-dropbox/5b051b9ccb30f115c332c6037d03d63d

package main

import (
	"context"
	"database/sql"
	"fmt"
	"log"
	"os"
	"time"

	_ "github.com/go-sql-driver/mysql"
)

func main() {
	if len(os.Args) != 2 {
		log.Fatalf("usage: %s <dbname>", os.Args[0])
	}
	dbName := os.Args[1]
	db, err := sql.Open("mysql", "root@/"+dbName)
	if err != nil {
		log.Fatal(err)
	}
	defer db.Close()

	db.SetMaxOpenConns(100)
	db.SetMaxIdleConns(100)

	if _, err := db.Exec("drop table if exists t"); err != nil {
		log.Fatal(err)
	}
	if _, err := db.Exec("create table t (id int not null auto_increment primary key)"); err != nil {
		log.Fatal(err)
	}

	ins, err := db.Prepare("insert into t (id) values (null)")
	if err != nil {
		log.Fatal(err)
	}

	sel, err := db.Prepare("select count(*) from t")
	if err != nil {
		log.Fatal(err)
	}

	for i := 0; i < 10; i++ {
		go func() {
			for i := 0; ; i++ {
				runTx(db, ins)
			}
		}()
	}
	for range time.Tick(time.Second) {
		var n int
		r := sel.QueryRow()
		if err := r.Scan(&n); err != nil {
			fmt.Println("select", err)
			continue
		}
		fmt.Printf("%d rows (should be 0)\n", n)
	}
}

func runTx(db *sql.DB, stmt *sql.Stmt) error {
	ctx, cancel := context.WithCancel(context.Background())
	quit := make(chan struct{})
	done := make(chan struct{})
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		fmt.Println("begin", err)
		return err
	}
	defer tx.Rollback()

	stmt = tx.Stmt(stmt)

	go func() {
		timer := time.NewTimer(time.Microsecond)
		defer timer.Stop()
		select {
		case <-quit:
		case <-timer.C:
		}
		cancel()
		close(done)
	}()
	defer func() {
		close(quit)
		<-done
	}()

	for i := 0; i < 10; i++ {
		if _, err := stmt.Exec(); err != nil {
			return err
		}
	}
	_ = tx.Rollback()
	return nil
}

outputs
1 rows (should be 0)
3 rows (should be 0)
4 rows (should be 0)
5 rows (should be 0)
^Csignal: interrupt

when you should never succeed in inserting any rows, since the transaction is always rolled back.

$ go version
go version go1.13.1 darwin/amd64

@methane

This comment has been hidden.

@dadkins-at-dropbox
Copy link
Author

@dadkins-at-dropbox dadkins-at-dropbox commented Oct 8, 2019

stmt = tx.Stmt(stmt) associates the prepared statement with the transaction, and that's the one the repro uses.

@methane
Copy link
Contributor

@methane methane commented Oct 9, 2019

I'm sorry, I've missed it. I confirm your repro.

@andybons andybons added this to the Unplanned milestone Oct 10, 2019
@dadkins-at-dropbox
Copy link
Author

@dadkins-at-dropbox dadkins-at-dropbox commented Oct 11, 2019

Here's another log trace, via the mysql driver, of driver.Tx.Rollback being called in the middle of a prepared driver.Stmt.ExecContext and wreaking havoc, because that driver is not expecting those calls to be interleaved:

[mysql] 2019/10/10 23:25:59 connection.go:577: [0xc000348fc0]stmt.ExecContext

*** COM_STMT_EXECUTE
[mysql] 2019/10/10 23:25:59 packets.go:155: [0xc000348fc0] :write len=10 seq=0
[mysql] 2019/10/10 23:25:59 packets.go:156: [0xc000348fc0]
00000000  17 01 00 00 00 00 01 00  00 00                    |..........|

*** column count
[mysql] 2019/10/10 23:25:59 packets.go:45: [0xc000348fc0] :read len=1 seq=1
[mysql] 2019/10/10 23:25:59 packets.go:80: [0xc000348fc0]
00000000  01                                                |.|

*** column def
[mysql] 2019/10/10 23:25:59 packets.go:45: [0xc000348fc0] :read len=37 seq=2
[mysql] 2019/10/10 23:25:59 packets.go:80: [0xc000348fc0]
00000000  03 64 65 66 00 00 00 0f  43 4f 4e 4e 45 43 54 49  |.def....CONNECTI|
00000010  4f 4e 5f 49 44 28 29 00  0c 3f 00 15 00 00 00 08  |ON_ID()..?......|
00000020  a1 00 00 00 00                                    |.....|

*** EOF
[mysql] 2019/10/10 23:25:59 packets.go:45: [0xc000348fc0] :read len=5 seq=3
[mysql] 2019/10/10 23:25:59 packets.go:80: [0xc000348fc0]
00000000  fe 00 00 03 00                                    |.....|

*** RACE: stmt.ExecContext is still active, shouldn't be calling tx.Rollback ***
[mysql] 2019/10/10 23:25:59 transaction.go:30: [0xc000348fc0]tx.Rollback
[mysql] 2019/10/10 23:25:59 packets.go:454: busy buffer
*** resets mc.sequence = 0 ***

*** packet header for row...
[mysql] 2019/10/10 23:25:59 packets.go:45: [0xc000348fc0] :read len=10 seq=4
*** ErrPktSyncMul? since mc.sequence got reset ***

*** disaster, we've treating the packet body as a new packet header, and the sequence number matches! we're going to lunch now while we wait to read 10MB that's never coming.
[mysql] 2019/10/10 23:25:59 packets.go:45: [0xc000348fc0] :read len=10027008 seq=0
@dadkins-at-dropbox
Copy link
Author

@dadkins-at-dropbox dadkins-at-dropbox commented Nov 5, 2019

It would be great if someone more familiar with this code could take a look. I think I've pretty much nailed down the problem, but I'm not really in a good position to propose a fix to this code which doesn't introduce new problems or break some intricate assumptions.

I've confirmed the following race:

Goroutine 1:
(*Stmt).ExecContext begins a prepared statement in a transaction.
(*Tx).grabConn obtains tx.closemu in read mode and returns a valid (*driveConn)

Goroutine 2:
(*Tx).awaitDone awakes on canceled context and calls (*Tx).rollback
(*Tx).rollback atomically changes tx.done from 0 to 1
(*Tx).rollback calls tx.txi.Rollback() while holding (*driverConn) mutex.

Goroutine 1:
(*Stmt).ExecContext calls resultFromStatement with *driverConn and *driverStmt
resultFromStatement locks ds, which is actually dc.mutex.
resultFromStatement executes statement with driverStmt.ExecContext
resultFromStatement unlocks dc.mutex.

Goroutine 2:
(*Tx).rollback closes prepared statements and calls (*Tx).close
(*Tx).close calls tx.cancel(), which is a no-op.
(*Tx).close calls tx.releaseConn() while holding tx.closemu.

It definitely allows a statement to execute on a connection after a rollback caused by context cancellation, which under mysql autocommits that statement unexpectedly.

Examining the code, it seems like we should hold tx.closemu for the duration of tx.Close or tx.Rollback, certainly while we're changing the state of tx.done. I tried the following workaround:

diff --git a/src/database/sql/sql.go b/src/database/sql/sql.go
index 0f5bbc01c9..abc892dc08 100644
--- a/src/database/sql/sql.go
+++ b/src/database/sql/sql.go
@@ -2021,8 +2021,8 @@ var ErrTxDone = errors.New("sql: transaction has already been committed or rolle
 func (tx *Tx) close(err error) {
        tx.cancel()
 
-       tx.closemu.Lock()
-       defer tx.closemu.Unlock()
+       //tx.closemu.Lock()
+       //defer tx.closemu.Unlock()
 
        tx.releaseConn(err)
        tx.dc = nil
@@ -2087,6 +2087,10 @@ func (tx *Tx) Commit() error {
                }
                return tx.ctx.Err()
        }
+
+       tx.closemu.Lock()
+       defer tx.closemu.Unlock()
+
        if !atomic.CompareAndSwapInt32(&tx.done, 0, 1) {
                return ErrTxDone
        }
@@ -2104,6 +2108,12 @@ func (tx *Tx) Commit() error {
 // rollback aborts the transaction and optionally forces the pool to discard
 // the connection.
 func (tx *Tx) rollback(discardConn bool) error {
+       // Problem: We can't lock tx.closemu while an oustanding
+       // Rows holding tx.closemu in R mode.
+       // We must call tx.cancel to release that first.
+       tx.cancel()
+       tx.closemu.Lock()
+       defer tx.closemu.Unlock()
        if !atomic.CompareAndSwapInt32(&tx.done, 0, 1) {
                return ErrTxDone
        }

It was unsuccessful.

First, I broke Issues 18719 #18719. The fix for that issue (https://go-review.googlesource.com/c/go/+/35550/) introduced the closemu mutex, which was supposed to be held exclusively while closing a tx and releasing its conn back to the pool, while queries hold closemu in read mode to prevent the close from occurring mid-query. Its test inserted a hook into tx.grabConn which expects to be able to wait for tx.done to change from 0 to 1 while it sits there holding tx.closemu in read mode. That no longer works, but the test could be changed.

The fix to Issue 18719 caused another issue: #20575. Namely, *Rows objects hold closemu in read mode, which prevents us from rolling back a transaction without first calling (*Rows).Close. The fix for that issue (https://go-review.googlesource.com/c/go/+/44812/) sticks a call to tx.cancel() in tx.close() prior to obtaining tx.closemu, which the (*Rows) code catches in order to unlock tx.closemu. My attempted fix broke this, because I moved the call to tx.closemu.Lock() earlier.

I can somewhat workaround this problem by inserting an extra call to tx.cancel() in tx.Rollback, but that's hacky and introduces a race between tx.rollback and tx.awaitDone also calling tx.rollback.

I think I'm close to a reasonable solution, but I don't quite know how to resolve the problems with tx.closemu. We need the exclusion between the various queries we can run on a transaction, and commit/rollback. But, perhaps a mutex is not the right solution to hold across multiple calls while iterating over a resultset. Or perhaps context cancellation is not the right mechanism to reclaim a connection while iterating over a rowset.

@dadkins-at-dropbox
Copy link
Author

@dadkins-at-dropbox dadkins-at-dropbox commented Nov 6, 2019

I now have a plausible solution, and a test case that it fixes (in addition to the repro program already posted). I'm awaiting approval from my employer to submit the change for review, but here it is in the meantime if anyone's interested. My company only uses even numbered versions of Go, so I'd like to get this fix into 1.14 if possible:

diff --git a/src/database/sql/sql.go b/src/database/sql/sql.go
index 0f5bbc01c9..a0fd05423c 100644
--- a/src/database/sql/sql.go
+++ b/src/database/sql/sql.go
@@ -2018,12 +2018,10 @@ var ErrTxDone = errors.New("sql: transaction has already been committed or rolle
 
 // close returns the connection to the pool and
 // must only be called by Tx.rollback or Tx.Commit.
+//
+// The transaction context must already have been canceled,
+// and closemu must locked.
 func (tx *Tx) close(err error) {
-       tx.cancel()
-
-       tx.closemu.Lock()
-       defer tx.closemu.Unlock()
-
        tx.releaseConn(err)
        tx.dc = nil
        tx.txi = nil
@@ -2090,6 +2088,18 @@ func (tx *Tx) Commit() error {
        if !atomic.CompareAndSwapInt32(&tx.done, 0, 1) {
                return ErrTxDone
        }
+
+       // cancel is called after done transitions from 0 to 1, but
+       // before we attempt to grab closemu, since context cancellation
+       // will cause any operations holding closemu in read mode to
+       // release their locks.
+       tx.cancel()
+
+       // closemu must be acquired exclusively before rolling back to
+       // allow any oustanding operations to finish.
+       tx.closemu.Lock()
+       defer tx.closemu.Unlock()
+
        var err error
        withLock(tx.dc, func() {
                err = tx.txi.Commit()
@@ -2107,6 +2117,18 @@ func (tx *Tx) rollback(discardConn bool) error {
        if !atomic.CompareAndSwapInt32(&tx.done, 0, 1) {
                return ErrTxDone
        }
+
+       // cancel is called after done transitions from 0 to 1, but
+       // before we attempt to grab closemu, since context cancellation
+       // will cause any operations holding closemu in read mode to
+       // release their locks.
+       tx.cancel()
+
+       // closemu must be acquired exclusively before rolling back to
+       // allow any oustanding operations to finish.
+       tx.closemu.Lock()
+       defer tx.closemu.Unlock()
+
        var err error
        withLock(tx.dc, func() {
                err = tx.txi.Rollback()
@methane
Copy link
Contributor

@methane methane commented Nov 8, 2019

Your patch looks good to me. Would you create a pull request?

@dadkins-at-dropbox
Copy link
Author

@dadkins-at-dropbox dadkins-at-dropbox commented Nov 8, 2019

@gopherbot
Copy link

@gopherbot gopherbot commented Jan 24, 2020

Change https://golang.org/cl/216240 mentions this issue: database/sql: prevent Tx statement from committing after rollback

@kardianos
Copy link
Contributor

@kardianos kardianos commented Apr 20, 2020

CL Ready, just waiting for a reviewer.

@andybons andybons added the NeedsFix label Apr 20, 2020
@odeke-em
Copy link
Member

@odeke-em odeke-em commented Apr 20, 2020

I've got you!

@gopherbot gopherbot closed this in d8f0a22 Apr 20, 2020
@ire-and-curses
Copy link

@ire-and-curses ire-and-curses commented May 13, 2020

Will this be released as a patch? Are there any mitigations we can apply in the meantime? Having some DB queries executed instead of rolled-back is potentially catastrophic.

@odeke-em
Copy link
Member

@odeke-em odeke-em commented May 13, 2020

@ire-and-curses so this issue has existed since Go1.12 and unfortunately because it wasn't a regression but rather a long standing bug, the policy is that we can only cherry pick to prior releases only regressions and security issues. Go1.15 release candidates and betas will be made between now and August 2020 when Go1.15 shall be released. Sorry about that.

You can however, clone Go, add the patch to a branch and build Go, and backport the respective fixes you'd like.

@leighmcculloch
Copy link
Contributor

@leighmcculloch leighmcculloch commented May 15, 2020

@odeke-em I believe this fix satisfies the requirements for a backport according to the minor version release policy because the issue is a serious issue that is causing databases to get into bad state where no work around is possible and updating to the latest release Go 1.14.3 does not fix the issue.

If patching Go is the suggested work around that suggests there is no work around in an application. Unfortunately building custom Go isn't an option for everyone as our product is open source and so we'd need to ask everyone who uses it to build with a custom Go.

@gopherbot please consider this for backport because this issue breaks production applications resulting in unexpected database state and cannot be fixed with a work around including updating the version of Go to the latest version.

@gopherbot
Copy link

@gopherbot gopherbot commented May 15, 2020

Backport issue(s) opened: #39101 (for 1.14).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

@odeke-em
Copy link
Member

@odeke-em odeke-em commented May 27, 2020

Awesome, thank you @leighmcculloch for the advocacy and for citing the backporting clause, it will be useful for folks to get it on Go1.14. The cherry pick has been approved and we shall get it up and approved shortly.

@romandvoskin
Copy link

@romandvoskin romandvoskin commented Jul 1, 2020

Awesome, thank you @leighmcculloch for the advocacy and for citing the backporting clause, it will be useful for folks to get it on Go1.14. The cherry pick has been approved and we shall get it up and approved shortly.

We're hitting this bug in production. Really looking forward to seeing it fixed in 1.14.5.

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 11, 2020

Change https://golang.org/cl/242101 mentions this issue: [release-branch.go1.14] database/sql: backport 3 Tx rollback related CLs

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 11, 2020

Change https://golang.org/cl/242102 mentions this issue: [release-branch.go1.14] database/sql: backport 3 Tx rollback related CLs

@dmitshur
Copy link
Member

@dmitshur dmitshur commented Jul 14, 2020

Based on #34775 (comment):

this issue has existed since Go1.12 and unfortunately because it wasn't a regression but rather a long standing bug

The backport policy requires that a fix must either be backported to both 1.14 and 1.13, or neither (see #34536 (comment)).

I've opened #40205 for this fix to be considered for backporting to 1.13 as well.

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 15, 2020

Change https://golang.org/cl/242522 mentions this issue: [release-branch.go1.13] database/sql: backport 5 Tx rollback related CLs

@odeke-em
Copy link
Member

@odeke-em odeke-em commented Jul 15, 2020

Thank you @dmitshur! I've mailed CL 242522 for the Go1.13.14 backport.

@dmitshur
Copy link
Member

@dmitshur dmitshur commented Jul 15, 2020

Thank you for doing that work, @odeke-em. The 1.13 backport issue is still in CherryPickCandidate state, so the release managers will need to decide whether it should be approved for backport. Having the backport CL ready makes that process easier.

gopherbot pushed a commit that referenced this issue Jul 16, 2020
Manually backported the subject CLs, because of lack of
Gerrit "forge-author" permissions, but also because the prior
cherry picks didn't apply cleanly, due to a tight relation chain.

The backport comprises of:
* CL 174122
* CL 216197
* CL 223963
* CL 216240
* CL 216241

Note:
Due to the restrictions that we cannot retroactively
introduce API changes to Go1.13.13 that weren't in Go1.13, the Conn.Validator
interface (from CL 174122, CL 223963) isn't exposed, and drivers will just be
inspected, for if they have an IsValid() bool method implemented.

For a description of the content of each CL:

* CL 174122:
database/sql: process all Session Resets synchronously

Adds a new interface, driver.ConnectionValidator, to allow
drivers to signal they should not be used again,
separatly from the session resetter interface.
This is done now that the session reset is done
after the connection is put into the connection pool.

Previous behavior attempted to run Session Resets
in a background worker. This implementation had two
problems: untested performance gains for additional
complexity, and failures when the pool size
exceeded the connection reset channel buffer size.

* CL 216197:
database/sql: check conn expiry when returning to pool, not when handing it out

With the original connection reuse strategy, it was possible that
when a new connection was requested, the pool would wait for an
an existing connection to return for re-use in a full connection
pool, and then it would check if the returned connection was expired.
If the returned connection expired while awaiting re-use, it would
return an error to the location requestiong the new connection.
The existing call sites requesting a new connection was often the last
attempt at returning a connection for a query. This would then
result in a failed query.

This change ensures that we perform the expiry check right
before a connection is inserted back in to the connection pool
for while requesting a new connection. If requesting a new connection
it will no longer fail due to the connection expiring.

* CL 216240:
database/sql: prevent Tx statement from committing after rollback

It was possible for a Tx that was aborted for rollback
asynchronously to execute a query after the rollback had completed
on the database, which often would auto commit the query outside
of the transaction.

By W-locking the tx.closemu prior to issuing the rollback
connection it ensures any Tx query either fails or finishes
on the Tx, and never after the Tx has rolled back.

* CL 216241:
database/sql: on Tx rollback, retain connection if driver can reset session

Previously the Tx would drop the connection after rolling back from
a context cancel. Now if the driver can reset the session,
keep the connection.

* CL 223963
database/sql: add test for Conn.Validator interface

This addresses comments made by Russ after
https://golang.org/cl/174122 was merged. It addes a test
for the connection validator and renames the interface to just
"Validator".

Updates #31480
Updates #32530
Updates #32942
Updates #34775
Fixes #40205

Change-Id: I6d7307180b0db0bf159130d91161764cf0f18b58
Reviewed-on: https://go-review.googlesource.com/c/go/+/242522
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
gopherbot pushed a commit that referenced this issue Jul 16, 2020
Manually backported the subject CLs, because of lack of
Gerrit "forge-author" permissions, but also because the prior
cherry picks didn't apply cleanly, due to a tight relation chain.

The backport comprises of:
* CL 174122
* CL 216197
* CL 223963
* CL 216240
* CL 216241

Note:
Due to the restrictions that we cannot retroactively
introduce API changes to Go1.14.6 that weren't in Go1.14, the Conn.Validator
interface (from CL 174122, CL 223963) isn't exposed, and drivers will just be
inspected, for if they have an IsValid() bool method implemented.

For a description of the content of each CL:

* CL 174122:
database/sql: process all Session Resets synchronously

Adds a new interface, driver.ConnectionValidator, to allow
drivers to signal they should not be used again,
separatly from the session resetter interface.
This is done now that the session reset is done
after the connection is put into the connection pool.

Previous behavior attempted to run Session Resets
in a background worker. This implementation had two
problems: untested performance gains for additional
complexity, and failures when the pool size
exceeded the connection reset channel buffer size.

* CL 216197:
database/sql: check conn expiry when returning to pool, not when handing it out

With the original connection reuse strategy, it was possible that
when a new connection was requested, the pool would wait for an
an existing connection to return for re-use in a full connection
pool, and then it would check if the returned connection was expired.
If the returned connection expired while awaiting re-use, it would
return an error to the location requestiong the new connection.
The existing call sites requesting a new connection was often the last
attempt at returning a connection for a query. This would then
result in a failed query.

This change ensures that we perform the expiry check right
before a connection is inserted back in to the connection pool
for while requesting a new connection. If requesting a new connection
it will no longer fail due to the connection expiring.

* CL 216240:
database/sql: prevent Tx statement from committing after rollback

It was possible for a Tx that was aborted for rollback
asynchronously to execute a query after the rollback had completed
on the database, which often would auto commit the query outside
of the transaction.

By W-locking the tx.closemu prior to issuing the rollback
connection it ensures any Tx query either fails or finishes
on the Tx, and never after the Tx has rolled back.

* CL 216241:
database/sql: on Tx rollback, retain connection if driver can reset session

Previously the Tx would drop the connection after rolling back from
a context cancel. Now if the driver can reset the session,
keep the connection.

* CL 223963
database/sql: add test for Conn.Validator interface

This addresses comments made by Russ after
https://golang.org/cl/174122 was merged. It addes a test
for the connection validator and renames the interface to just
"Validator".

Updates #31480
Updates #32530
Updates #32942
Updates #34775
Fixes #39101

Change-Id: I043d2d724a367588689fd7d6f3cecb39abeb042c
Reviewed-on: https://go-review.googlesource.com/c/go/+/242102
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants
You can’t perform that action at this time.