job.completed o un job.failed, exactamente uno por desenlace de job. Estas notificaciones son un contrato obligatorio del producto — el worker se niega a arrancar con el streaming deshabilitado en lugar de tragárselas silenciosamente.
Los eventos viajan en el sobre CloudEvents compartido, publicados sobre RabbitMQ: cada evento se enruta al exchange nombrado por RABBITMQ_JOB_EVENTS_EXCHANGE con la clave del evento como routing key AMQP (job.completed, job.failed). Ambos eventos están respaldados por outbox: la fila del outbox se escribe de forma durable y un relay la publica, reintentando durante las caídas del broker; un reparador reemite los eventos terminales que nunca llegaron al broker. La entrega es at-least-once — deduplica por ce-id, que es determinista por desenlace de job: fetcher.job.<status>.<jobID>, así que cada reemisión del mismo hecho lleva el mismo id. El ce-subject es el id del job; los despliegues single-tenant estampan ce-tenantid como single-tenant.
A diferencia de la mayoría de los payloads de Lerian, los eventos de job de Fetcher usan claves en camelCase — reflejan la superficie REST de Fetcher.
Eventos de job
El bloque
result describe el artefacto producido: dónde se escribió, su tamaño y conteo de filas, el formato de salida y — cuando la protección de resultados está habilitada — los descriptores de integridad (HMAC) y protección que un consumidor usa para verificar el artefacto antes de confiar en él.