Crate headgate_mysql 

headgate-mysql — the MySQL backend (push wakeups).

Same tier as Postgres for the feature that matters most: InnoDB transactions make transactional enqueue work identically. Two loud, permanent differences (push wakeups):

• No push wakeup. MySQL has no LISTEN/NOTIFY; the wakeup latency floor is the poll interval. as_notifying() is None, honestly, forever.
• No partial indexes. job uniqueness uniqueness rides GENERATED columns that are NULL when the job is not in a unique-eligible state (see migrations/0001_init.sql).

The admission gate: Postgres uses one data-modifying CTE; MySQL has neither data-modifying CTEs nor RETURNING, so per store port boundary (“each natively, none pretending to be the other”) the atomic unit here is ONE READ COMMITTED InnoDB transaction: lock buckets → policy read (queries/eligible.sql — clause-for-clause the PG gate) → lock survivors with the STATE RE-CHECK + FOR UPDATE SKIP LOCKED → claim + lease → read claimed rows → spend buckets → charge deficits → COMMIT. Time comes from the store (NOW(3)), never the caller, read once per transaction.

Structs

MysqlStore

failure classification caller-supplied pool; mysql_async::Pool is cheaply cloneable and this crate never disconnects it. If T once/step_once callbacks may retain transactions concurrently across workers sharing the pool, configure T + 2 connections. Unlike Postgres there is no notifier connection outside that cap. Live bounded-pool evidence and the nested-acquisition caveat are in docs/connection-budget.md.

MysqlStoreOptions

MysqlTx

A caller-owned store transaction. Managed manually (START TRANSACTION on a dedicated pooled Conn) exactly like PgTx: mysql_async’s borrowing Transaction type cannot live in a dyn TxHandle. Dropping without commit returns the Conn to the pool, whose reset-on-reuse rolls the transaction back server-side.