# Ritardi persistenti

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](https://queuety.inline0.dev/it/docs/workflows/conditional) 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 );
```