~bigbes/core-go

ref: cfae7baecb8910cf4b28b3b9ab4df8e0b50dc2b3 core-go/database/middleware.go -rw-r--r-- 1.6 KiB
a06a6247 — Simon Ser 3 years ago
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.
43a2be15 — Simon Ser 3 years ago
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.
209e1a86 — Simon Ser 3 years ago
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.
7ccaeb92 — Drew DeVault 5 years ago
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.
a7d80e21 — Drew DeVault 5 years ago
database: handle Commit/Rollback errors
33562018 — Drew DeVault 5 years ago
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.
14f4b921 — Drew DeVault 5 years ago
Expand context for work queues
bfc744fc — Drew DeVault 5 years ago
Add basic auth tests
1d2a30cb — Drew DeVault 5 years ago
Import GQL server interfaces from gql.sr.ht