grabMariaDBClient reused global.MARIADB_CLIENT whenever the requested
config matched global.CONFIG. It never checked that the client was made
from that config or was still open. init() sets global.CONFIG before
creating the client, so a re-init after a close, or a config change, got
back a closed or wrong client.
- Remember the cache key each client was created with, and compare that
- Wrapping close() drops the client from the cache and unsets
global.MARIADB_CLIENT, so the next grab or ensureInit makes a new one
- resolveClient goes through grabMariaDBClient instead of repeating the
global.CONFIG comparison
- Remove the queue test's workaround for this
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A table with `queue_table` set works as a job queue that many workers can
pull from at once. Claims use SELECT ... FOR UPDATE SKIP LOCKED over the
idx_queue_claim index order, so each job goes to one worker and only the
claimed rows are locked.
- Schema: adds the queue_* columns and the idx_queue_claim /
idx_queue_lease indexes. Declaring these names yourself is an error.
- `queue_table` accepts `true` or { max_attempts, lease_ms, keep_completed }
- BunMariaDB.queue: push, claim, ack, fail, extend, cancel
- Statuses: pending, processing, done, failed, cancelled
- Leases use the database clock. Expired leases are reclaimed (or
dead-lettered on the last attempt) and old lock tokens stop working.
- insert/update can't set queue state fields. update/delete skip claimed
jobs.
Tests: allow the test container's self-signed certificate, and give the
queue test its own client so it doesn't reuse one closed by db.test.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
tbenandClaude Opus 5.5