Los correos, los avisos de tiempo real y las notificaciones van por la cola (Redis). Si un trabajo falla todas sus veces, queda en failed_jobs y se registra un evento del sistema. Desde el panel de salud, el Super admin los ve y decide si reintentarlos o descartarlos.
Paso a paso
- WorkerUn job agota sus intentos
- Base de datosQueda en failed_jobs y deja un evento
Evento
JobFailedagrupado por huella ensystem_events. El contenido del job (que puede llevar datos personales) se queda en la base, cifrado si es un correo. - Super adminAbre "Jobs fallidos" desde Salud
Hasta 50 recientes, sin su contenido: nombre, cola, fecha y la primera línea del error. Basta
system.health.viewpara verlos. - Super admin¿Reintenta o descarta?
- APICon código, ¿existen los elegidos?
Uno, varios o todos (
POST /system/failed-jobs/retry), con las protecciones de las acciones de sistema. Si otra persona ya los atendió, responde 404. - WorkerVuelven a la cola y se registra cuántos
system_jobs_retriedcon el número enadmin_actions. - APICon código, ¿existe el job?
DELETE /system/failed-jobs/{id}. - Base de datosLo borra y registra cuál era
system_job_discardedcon el nombre y la cola del job.
Qué ve la persona en cada error
| Código | HTTP | Cuándo | Mensaje en pantalla |
|---|---|---|---|
FAILED_JOB_NOT_FOUND | 404 | Otra persona ya lo reintentó o lo descartó | Ese job ya no está en la lista: otra persona lo reintentó o lo descartó. Actualiza la lista. |
NO_FAILED_JOBS | 409 | “Reintentar todos” sin jobs fallidos | No hay jobs fallidos para reintentar. |
REAUTHENTICATION_LOCKED | 423 | Cinco códigos incorrectos en un minuto | Escribiste varios códigos incorrectos seguidos. Espera {wait} y vuelve a intentarlo. |
Dónde está en el código
ManageFailedJobs: ver, reintentar y descartar.DatabaseFailedJobs: lectura sin el contenido.SystemServiceProvider: el evento al fallar un job.- Diccionario: failed_jobs.
- Explicación: Módulo System.