Worker::$flushStickyConnections = true; es una sola línea en un service provider y, para mí, es lo más interesante de Laravel 13.36. No porque sea ingenioso, sino porque plantea en voz baja una pregunta: ¿tus jobs de cola son de verdad independientes entre sí? Sospecho que a muchos la respuesta nos resultaría incómoda.

<?php

use Illuminate\Queue\Worker;

// Reset sticky read/write state before each queued job
Worker::$flushStickyConnections = true;

Repaso rápido de lo que ha cambiado. Si tu configuración de base de datos de lectura/escritura tiene sticky activado, una escritura manda las lecturas posteriores de ese ciclo al primario, para que puedas leer lo que acabas de escribir. Dentro de una petición web tiene sentido, porque empieza y termina. Un worker de cola, en cambio, no termina nunca. Así que el job 41 actualiza una fila, el job 42 es un informe que debería ir a la réplica, y acaba leyendo del primario porque el worker todavía recuerda la escritura del job 41. Multiplica eso por un pool de workers con mucho tráfico y tu primario está sirviendo las consultas de informes que pagaste para que absorbiera una réplica. La nueva propiedad estática reinicia ese estado antes de cada job. Es opcional, y el framework la deja desactivada porque algunas aplicaciones dependen del comportamiento antiguo.

Esa concesión merece que la tomemos en serio. Hay un patrón legítimo en el que un job escribe y el siguiente, encadenado o despachado justo después, tiene que ver esa escritura al instante, y un retraso de replicación de apenas 300 milisegundos le daría datos obsoletos. Si activas el flag a ciegas, ese job empieza a fallar de formas que solo aparecen bajo carga. Mantenerlo desactivado por defecto es lo correcto en una versión menor. Nadie quiere una actualización menor que cambie sin avisar qué servidor responde a sus SELECT.

Aun así, yo lo activaría en mis propias apps y trataría lo que se rompa como un bug que todavía no había encontrado. Un job que solo lee bien porque un job anterior cayó por casualidad en el mismo proceso del worker está confiando en la suerte de la planificación. Pon dos workers en lugar de uno, reinicia Horizon a las 03:17 durante un deploy, y la garantía desaparece, porque en realidad nunca lo fue. Si el job B necesita leer sus propias escrituras, debería decirlo de forma explícita, fijando su consulta a la conexión de escritura, y no depender del estado que le haya dejado un vecino.

El resto de cambios relacionados con colas en 13.36 apuntan en la misma dirección, y por eso no veo el flag como algo aislado. Los mailables en cola ahora respetan #[DeleteWhenMissingModels], así que un correo OrderShipped de un pedido que se ha borrado mientras tanto se descarta en lugar de lanzar ModelNotFoundException. También respetan #[FailOnTimeout], de modo que un envío que agota el tiempo se marca como fallido en vez de reintentarse y acabar quizá en un correo duplicado. Ese viene con una advertencia: puede que el proveedor ya hubiera aceptado el mensaje antes de que saltara el timeout. Incluso la salida JSON del worker incluye ahora información de la conexión en los mensajes de paused, resumed y stopped. Cada uno de estos arreglos hace que el job describa su propio comportamiento en lugar de dejar que el runtime lo adivine.

Y en esta misma versión el framework sí cambió un valor por defecto en otro sitio, lo que hace útil el contraste. Los eventos que solo van a Mercure ahora se publican de forma síncrona, y necesitas MERCURE_ASYNC=true más un MERCURE_URL para que vuelvan a pasar por la cola. Así que está claro que los mantenedores están dispuestos a cambiar valores por defecto cuando creen que el anterior sorprendía a más gente de la que ayudaba. El flushing sticky no ha recibido ese trato, y apostaría a que es por prudencia, no porque el comportamiento antiguo sea el mejor diseño. Si la adopción de 13.36 va bien, me gustaría que la próxima versión mayor lo invirtiera y que arrastrar estado entre jobs pasara a ser algo que activas tú a propósito.

Los builders fluidos Rule::url()->protocols(['https']), DB::olap() para informes en PlanetScale y Vitess, y el arreglo del escapado de barras invertidas en el correo Markdown también merecen tu tarde de actualización, y el de Markdown debería ir de los primeros si hay input de usuarios que acaba en tus plantillas de correo. Pero son añadidos: los aprovechas escribiendo código nuevo. El flag sticky va sobre tu código existente, y auditarlo te obliga a averiguar qué jobs dependen en secreto unos de otros. Así que tengo curiosidad: ¿ya lo has activado, y descubriste que algo de tu grafo de jobs dependía de leer sus propias escrituras entre un job y otro? ¿O crees que el sticky a nivel de worker es una funcionalidad que debería seguir siendo el valor por defecto?