Auth writes that queue a job

A plugin writes a verification row, then sends the link. That is two steps, and the process can die between them. Then you have sent a link for a row that rolled back, or written a row nobody is ever told about.

withAuthTransactionalQueue makes it one step.

The call

It comes from questpie/auth. It takes a Better Auth context and a callback.

import { withAuthTransactionalQueue } from "questpie/auth";

import { app } from "#questpie";
import sendVerification from "./jobs/send-verification";

export async function sendAuthVerification(input: {
	identifier: string;
	hashedToken: string;
	rawToken: string;
	expiresAt: Date;
}) {
	const context = await app.auth.$context;

	return withAuthTransactionalQueue({ context }, async ({ auth, publish }) => {
		await auth.create({
			model: "verification",
			data: {
				identifier: input.identifier,
				value: input.hashedToken,
				expiresAt: input.expiresAt,
			},
		});
		return publish(
			sendVerification,
			{ identifier: input.identifier, token: input.rawToken },
			{ idempotencyKey: `auth-verification:${input.identifier}:v1` },
		);
	});
}

Inside a Better Auth plugin, pass the endpoint's own ctx instead. It already carries the context this needs, so you skip the $context read.

The callback receives two things and nothing else.

Both halves commit together. A throw anywhere in the callback rolls back the row and the dispatch. publish resolves to the dispatch id, and the outer call resolves to whatever your callback returned.

What it refuses

Three things throw, and none of them leaves a row or a dispatch behind.

The first one is a fence, not a bug in your code. QUESTPIE binds the bridge to its own Better Auth adapter, and it registers that plugin first. A plugin of yours that replaces the adapter loses the bridge rather than running the write outside the transaction.

The job has to be the one you registered

publish matches the definition you pass against the values in your queue config, by identity. It does not match on name. So import the object your jobs/ file exported and pass that.

A second job object carrying the same name is still a different object, and it is rejected. That is what stops a plugin naming its way into a job nobody gave it.

The payload is always encrypted

Every publish through this bridge sets secretPayload. That is the point of it, because a verification token is the value you cannot afford to leave sitting in a broker. It also means the requirements on Secret payloads apply here every time.

Only pg-boss qualifies today. On BullMQ or Cloudflare Queues the publish throws rather than leave a wrapped key behind.

After the commit

The dispatch lands in the same ledger every transactional publish uses. So a crash between the commit and the broker accepting the job is recoverable, and a worker or a queue.drain() pass relays it later. Read the outcome with queue.getReceipt(dispatchId).

Two callers racing under one idempotencyKey resolve to one dispatch. The second reservation finds the first one and returns its id. No second job is queued.

Where each topic lives