Read-after-write goes to the primary, always

A read immediately following a write is the one query that cannot tolerate replication lag, and it is also the query most likely to be written without thinking.

// the write, then the read that must see it
$order = Order::create($attributes);

DB::connection()->table('orders')->where('id', $order->id)->first();
// ↑ may hit a replica, and may find nothing

Order::onWriteConnection()->find($order->id);

// and the framework's own sticky mode, per request
// 'sticky' => true — reads go to the primary AFTER any write

Sticky mode covers the common case automatically and does it per request, which means a queue job dispatched inside that request and executed elsewhere is not covered. That is the gap that produces the confusing bug: the web request is consistent and the worker reading the same row a second later is not. Dispatching after commit and reading on the write connection in the job are the two halves of the fix.