# Journalisation

Queuety enregistre chaque événement de tâche et de workflow dans la table de base de données `queuety_logs`. Il n’y a pas de fichiers journaux. Toutes les entrées peuvent être interrogées via PHP API et CLI.

## Types d’événements

Chaque entrée du journal comporte un type d’événement issu de l’énumération `LogEvent` :

| Événement | Description |
|---|---|
| `started` | Exécution de la tâche démarrée |
| `completed` | Tâche terminée avec succès |
| `failed` | Une tentative a levé une exception et sera relancée (la dernière tentative n’enregistre que `buried`) |
| `buried` | La tâche a épuisé toutes ses tentatives de relance |
| `retried` | Une nouvelle tentative de la tâche a été planifiée |
| `workflow_started` | Le workflow a été distribué |
| `workflow_completed` | Toutes les étapes du workflow sont terminées |
| `workflow_failed` | Une étape du workflow a échoué définitivement |
| `workflow_paused` | Le workflow a été mis en pause |
| `workflow_resumed` | Le workflow a repris |
| `workflow_cancelled` | Le workflow a été annulé |
| `workflow_rewound` | Le workflow est revenu à une étape précédente |
| `workflow_forked` | Le workflow a été bifurqué en un nouveau workflow |
| `workflow_deadline_exceeded` | Le workflow a dépassé son échéance `must_complete_within()` |
| `debug` | Message de niveau débogage (lorsque `QUEUETY_DEBUG` est activé) |

## Champs du journal

Chaque entrée du journal contient :

| Champ | Description |
|---|---|
| `id` | ID auto-incrémenté |
| `event` | Chaîne du type d’événement |
| `handler` | Nom du gestionnaire ou de la classe |
| `job_id` | ID de la tâche associée (nullable) |
| `workflow_id` | ID du workflow associé (nullable) |
| `step_index` | Index de l’étape du workflow (nullable) |
| `attempt` | Numéro de tentative |
| `duration_ms` | Durée d’exécution en millisecondes |
| `error_message` | Message d’erreur en cas d’échec |
| `created_at` | Horodatage |

## Interroger les journaux via PHP

```php
$logger = Queuety::logger();

// Logs for a specific job
$logs = $logger->for_job( 42 );

// Logs for a specific workflow
$logs = $logger->for_workflow( 7 );

// Logs for a specific handler
$logs = $logger->for_handler( 'send_email', 50 );

// Logs for a specific event type
$logs = $logger->for_event( \Queuety\Enums\LogEvent::Failed, 50 );

// Logs since a datetime
$logs = $logger->since( new \DateTimeImmutable( '-1 hour' ), 100 );
```

## Interroger les journaux via CLI

```bash
# Recent logs (last 24 hours)
wp queuety log

# Logs for a specific job
wp queuety log --job=42

# Logs for a specific workflow
wp queuety log --workflow=7

# Logs for a handler
wp queuety log --handler=send_email

# Logs for an event type
wp queuety log --event=failed

# Logs since a datetime
wp queuety log --since="2025-01-01 00:00:00"

# Custom limit and format
wp queuety log --limit=100 --format=json
```

## Conservation des journaux

Les journaux sont conservés jusqu’à leur purge. La constante `QUEUETY_LOG_RETENTION_DAYS` est lue par `Config::log_retention_days()`, mais rien ne l’utilise encore : elle ne purge donc rien ([#15](https://github.com/inline0/queuety/issues/15)). La sous-commande `wp queuety log purge` est également inaccessible ([#11](https://github.com/inline0/queuety/issues/11)).

Purger depuis PHP, par exemple avec votre propre tâche planifiée ou via `wp eval` :

```php
$count = Queuety::logger()->purge( 30 );
```