Vai al contenuto

Ritardi persistenti

Visualizza come Markdown Modifica su GitHub Documentazione di 2cc7b2b

I workflow possono fare una pausa di durata fissa tra i passaggi usando il metodo del generatore delay(). I passaggi di attesa sono persistenti: il ritardo viene memorizzato nel database, quindi resta valido dopo il riavvio dei worker, i deploy e i riavvii del server.

Il metodo ->delay()

Aggiungete un passaggio di attesa in qualsiasi punto della catena del workflow:

PHP
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 ] );

Il workflow:

  1. Esegue SendWelcomeEmailHandler
  2. Attende 1 giorno
  3. Esegue SendFollowUpEmailHandler
  4. Attende 3 giorni
  5. Esegue SendFinalEmailHandler

Parametri di durata

Il metodo delay() accetta qualsiasi combinazione di parametri di durata denominati:

Parametro Tipo Descrizione
$seconds int Secondi di attesa
$minutes int Minuti di attesa
$hours int Ore di attesa
$days int Giorni di attesa

Tutti i valori vengono sommati. Questi sono equivalenti:

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

È possibile combinarli:

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

Come funzionano i passaggi di attesa

Quando un workflow raggiunge un passaggio di attesa, Queuety avvia un job interno __queuety_delay con la colonna available_at impostata sull'ora corrente più la durata del ritardo. Il job rimane nel database e nessun worker lo acquisisce finché il ritardo non è trascorso.

Questo significa che:

  • Nessun polling. I worker non controllano ripetutamente il ritardo. Il job diventa semplicemente disponibile allo scadere del tempo.
  • Nessun consumo di memoria. Durante l'attesa non è in esecuzione nulla. Il ritardo esiste solo come riga del database.
  • Resiste ai riavvii. Se il worker si riavvia, il job di attesa rimane in coda con il timestamp available_at corretto.

Quando il job di attesa viene acquisito dopo il ritardo, il workflow avanza automaticamente al passaggio successivo.

Esempio: notifiche ritardate

Inviate un promemoria 1 ora dopo la registrazione di un utente, ma solo se non ha completato l'onboarding:

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

Il passaggio CheckOnboardingHandler può esaminare lo stato e usare la ramificazione condizionale per saltare il promemoria se l'onboarding è già stato completato.

Esempio: ripetizione con attesa progressiva

Inserite ritardi intenzionali tra i passaggi simili a tentativi ripetuti:

PHP
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' ] );

Più ritardi

Un workflow può contenere un numero qualsiasi di passaggi di attesa. Ogni ritardo è indipendente ed è tracciato nello stato del workflow con un nome sequenziale (delay_0, delay_1 e così via).

PHP
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 );