Blake Gentry

I think we can instead tweak this to use [`context.WithoutCancel`](https://pkg.go.dev/context#WithoutCancel). It was brand new when we wrote the initial job fetching code and wouldn’t have been supported by the two...

Should be resolved by https://github.com/riverqueue/river/pull/514 in the next release, thanks for the report!

I'm not opposed to this idea, though as my comments in #399 show it's more complex than it may seem at first glance. Particularly for _removal_ because of complex shutdown...

I think we can call this closed for now? There's a mechanism to add new queues at runtime, though not to remove them. We can let that bubble up as...

Same one [here](https://github.com/riverqueue/river/actions/runs/11227565522/job/31209997605?pr=639) again today: ``` ================== WARNING: DATA RACE Write at 0x00c0004a7260 by goroutine 26148: github.com/jackc/pgx/v5/pgconn.(*PgConn).asyncClose() /home/runner/go/pkg/mod/github.com/jackc/pgx/[email protected]/pgconn/pgconn.go:674 +0x55 github.com/jackc/pgx/v5/pgconn.(*ResultReader).receiveMessage() /home/runner/go/pkg/mod/github.com/jackc/pgx/[email protected]/pgconn/pgconn.go:1661 +0x10c4 github.com/jackc/pgx/v5/pgconn.(*ResultReader).readUntilRowDescription() /home/runner/go/pkg/mod/github.com/jackc/pgx/[email protected]/pgconn/pgconn.go:1641 +0x6e github.com/jackc/pgx/v5/pgconn.(*PgConn).execExtendedSuffix() /home/runner/go/pkg/mod/github.com/jackc/pgx/[email protected]/pgconn/pgconn.go:1220 +0x2f9 github.com/jackc/pgx/v5/pgconn.(*PgConn).ExecPrepared() /home/runner/go/pkg/mod/github.com/jackc/pgx/[email protected]/pgconn/pgconn.go:1165...

Whoops, yeah I wasn't sure if people even needed this when rewriting the unique jobs implementation and never got around to getting back to implement it. Sorry about that! Looks...

Hmm, the copy variant will never be able to do things like handle conflicts on unique inserts. I don’t think it’s appropriate for a primary API for that reason. But...

> I wonder if there could be a "no return" flag passed as a function option somewhere that'd just have the normal "insert many" that'd use the fast path, and...

Please check out the new `rivertest.Worker` type in #753. I think it makes testing workers _much_ easier! It should go out in the next release tomorrow. The one caveat is...

@alexstuckeyjump if you're wanting your real running workers to operate with a full pgx pool but in tests you want to test them within a transaction, the typical pattern for...