Laravel 13.36 lets queue workers flush sticky database connections
A new opt-in flag resets read/write routing between queue jobs, and the same release adds DB::olap() for PlanetScale and makes Mercure broadcasts synchronous by default.
Laravel 13.36.0 gives queue workers a way to flush sticky database connections between jobs. With sticky connections on, one job’s write sends every later read in that worker to the write connection instead of a replica, and in a long-running worker process that routing never resets on its own.
Set Worker::$flushStickyConnections = true; in AppServiceProvider::boot() and the worker resets that state before each job. It defaults to false, since some jobs rely on reading data a previous job in the same process just wrote. The same release adds DB::olap() and isVitess() to the MySQL connection, which switch to PlanetScale’s OLAP workload for a callback to get past Vitess’s 100,000-row limit on standard queries, then switch back. It also makes Mercure broadcasts synchronous by default, so events fire immediately instead of queueing; set MERCURE_ASYNC=true to keep the old behaviour.
// AppServiceProvider::boot()
Worker::$flushStickyConnections = true;
Why it matters: anyone running read replicas behind sticky connections has had jobs silently pile onto the write connection for the rest of a worker’s life after one write. This flag fixes that without switching off stickiness entirely, at the cost of checking your jobs don’t depend on reading their own recent writes.