database: add WithReadOnlyTx
database: don't panic on context.DeadlineExceeded
Checking context.Cancelled is not enough, I also see the same issue
with context.DeadlineExceeded:
panic: Transaction error: driver: bad connection
Closure error: context deadline exceeded
goroutine 66664 [running]:
git.sr.ht/~sircmpwn/core-go/database.WithTx({0x5578e1847a58, 0xc0002c44e0}, 0x50?, 0xc000285f38)
e7b8e02696a1">git.sr.ht/~sircmpwn/core-go@v0.0.0-20231129165057-e7b8e02696a1/database/middleware.go:74 +0x2ce
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders.fetchUsersByID.func1({0xc0002cf190, 0x1, 0x1})
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders/middleware.go:34 +0x118
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders.(*usersByIDLoaderBatch).end(...)
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders/usersbyidloader_gen.go:222
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders.(*usersByIDLoaderBatch).startTimer(0xc00044a360, 0xc00042d380)
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders/usersbyidloader_gen.go:218 +0xe7
created by git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders.(*usersByIDLoaderBatch).keyIndex
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders/usersbyidloader_gen.go:191 +0x119
database: print both errors in WithTx
Make it easier to debug panics by printing both errors instead of
sending one of them to /dev/null.
database/middleware: fix error value used in panic
We were checking txErr, but panic'ing with err.
Fixes: a06a6247898c ("database: don't panic with ErrBadConn")
database: don't panic with ErrBadConn
Sometimes we're panic'ing like so:
panic: driver: bad connection
goroutine 9333 [running]:
git.sr.ht/~sircmpwn/core-go/database.WithTx({0x561c2e623478, 0xc0002b6ed0}, 0x50?, 0xc00025ff38)
65b1657b30a1">git.sr.ht/~sircmpwn/core-go@v0.0.0-20230816134313-65b1657b30a1/database/middleware.go:57 +0x1fc
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders.fetchUsersByID.func1({0xc0002d80f0, 0x1, 0x1})
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders/middleware.go:34 +0x118
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders.(*usersByIDLoaderBatch).end(...)
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders/usersbyidloader_gen.go:222
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders.(*usersByIDLoaderBatch).startTimer(0xc0004e5380, 0xc0000e5140)
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders/usersbyidloader_gen.go:218 +0xe7
created by git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders.(*usersByIDLoaderBatch).keyIndex
git.sr.ht/~sircmpwn/builds.sr.ht/api/loaders/usersbyidloader_gen.go:191 +0x119
I believe this is a pq bug, see the linked bug report. Stop
panic'ing in that case.
database/middleware: don't use sql.Conn in WithTx
We can just use sql.DB instead of sql.Conn here. Simplifies the
code and reduces the risk of getting "bad connection" errors.
database/middleware: do not recover/panic in defer
defer always runs after a panic. There is no need to recover and
re-panic, we can just unconditionally tx.Rollback() (it will
silently error out if the transaction has already been committed or
rolled back).
This fixes the stack trace of the panic being incorrect. It points
to this function instead of the real culprit.
database: panic on errors from Commit/Rollback
The previous change would eat the error from fn(tx); in truth we should
ensure that it is returned to the caller. This panics instead if an
error occurs during Commit or Rollback. I'm not sure of what scenarios
would cause this to occur, but they all probably deserve further
investigation - a panic will raise it to our attention.
database: handle Commit/Rollback errors
database.WithTx: rollback if func returns error
Previously, this only rolled back if the called function panicked. This
updates it to also roll back if the called function returns an error.
Expand context for work queues
Import GQL server interfaces from gql.sr.ht