Demoras duraderas

Los flujos de trabajo pueden pausarse durante un tiempo fijo entre pasos mediante el método de constructor delay(). Los pasos de demora son duraderos: la demora se almacena en la base de datos, por lo que se conserva tras reiniciar los workers, implementar cambios y reiniciar el servidor.

El método ->delay()

Añada un paso de demora en cualquier punto de la cadena del flujo de trabajo:

use Queuety\Queuety;

Queuety::workflow( 'drip_campaign' )
    ->then( SendWelcomeEmailHandler::class )
    ->delay( days: 1 )
    ->then( SendFollowUpEmailHandler::class )
    ->delay( days: 3 )
    ->then( SendFinalEmailHandler::class )
    ->dispatch( [ 'user_id' => 42 ] );

El flujo de trabajo hará lo siguiente:

1. Ejecutar SendWelcomeEmailHandler
2. Esperar 1 día
3. Ejecutar SendFollowUpEmailHandler
4. Esperar 3 días
5. Ejecutar SendFinalEmailHandler

Parámetros de duración

El método delay() acepta cualquier combinación de parámetros de duración con nombre:

Todos los valores se suman. Estos ejemplos son equivalentes:

->delay( seconds: 3600 )
->delay( minutes: 60 )
->delay( hours: 1 )

Puede combinarlos:

->delay( hours: 1, minutes: 30 ) // 90 minutes total

Cómo funcionan los pasos de demora

Cuando un flujo de trabajo llega a un paso de demora, Queuety despacha un trabajo interno __queuety_delay con la columna available_at establecida en la hora actual más la duración de la demora. El trabajo permanece en la base de datos y ningún worker lo reclama hasta que transcurre la demora.

Esto significa que:

• Sin consultas periódicas. Los workers no comprueban la demora repetidamente. El trabajo simplemente queda disponible cuando llega el momento.
• Sin uso de memoria. No se ejecuta nada durante la espera. La demora existe únicamente como una fila de la base de datos.
• Resiste los reinicios. Si se reinicia el worker, el trabajo de demora sigue en la cola con la marca de tiempo available_at correcta.

Cuando se reclama el trabajo de demora una vez transcurrido ese tiempo, el flujo de trabajo avanza automáticamente al siguiente paso.

Ejemplo: notificaciones diferidas

Envíe un recordatorio 1 hora después de que un usuario se registre, pero solo si aún no ha completado la incorporación:

Queuety::workflow( 'onboarding_reminder' )
    ->then( CreateAccountHandler::class )
    ->delay( hours: 1 )
    ->then( CheckOnboardingHandler::class )
    ->then( SendReminderHandler::class )
    ->dispatch( [ 'email' => 'user@example.com' ] );

El paso CheckOnboardingHandler puede inspeccionar el estado y usar ramificación condicional para omitir el recordatorio si la incorporación ya se ha completado.

Ejemplo: reintentos con espera progresiva

Inserte demoras deliberadas entre los pasos de reintento:

Queuety::workflow( 'poll_external_api' )
    ->then( CheckStatusHandler::class, 'check' )
    ->delay( minutes: 5 )
    ->then( CheckStatusHandler::class, 'recheck' )
    ->delay( minutes: 15 )
    ->then( CheckStatusHandler::class, 'final_check' )
    ->then( ProcessResultHandler::class )
    ->dispatch( [ 'external_id' => 'abc-123' ] );

Varias demoras

Un flujo de trabajo puede contener cualquier cantidad de pasos de demora. Cada demora es independiente y se registra con un nombre secuencial (delay_0, delay_1, etc.) en el estado del flujo de trabajo.

Queuety::workflow( 'multi_step_drip' )
    ->then( StepA::class )
    ->delay( hours: 2 )
    ->then( StepB::class )
    ->delay( days: 1 )
    ->then( StepC::class )
    ->delay( minutes: 30 )
    ->then( StepD::class )
    ->dispatch( $payload );