GET /v1/reports/{id} para averiguarlo.
GET /v1/streaming/events describe el contrato en forma legible por máquina. Esta página cubre el lado del consumidor: qué te dice el manifiesto, qué llega por el cable y qué lleva cada evento.
La operación de manifiesto
Obtener eventos de streaming devuelve el catálogo estático de eventos. Está autenticada como cualquier otra operación, responde
Cache-Control: no-store y se sirve tanto si este despliegue publica eventos como si no. Léela al arrancar para comprobar que tu consumidor y Reporter coinciden en el contrato.
La respuesta tiene cuatro campos:
El topic es una clave de enrutamiento
Cada entrada de evento lleva un
topic. Es una clave lógica de enrutamiento: un identificador estable para un flujo de eventos, compuesto a partir del source del publicador y de la definición del evento. Con el source que Reporter anuncia, report.requested se compone así:
RABBITMQ_REPORT_EVENTS_EXCHANGE, y la clave de enrutamiento de cada mensaje es la clave de definición del evento tal cual — report.finished, deadline.delivery_reverted, guiones bajos incluidos.
El catálogo de eventos
Existen doce definiciones de evento repartidas entre los dos modos de ejecución.
Este canal es solo de publicación. Reporter emite estos eventos y no consume ninguno.
Entrega
La clase de la tabla anterior selecciona una política de entrega.
Un evento de clase Critical, por tanto, nunca publica directamente al broker. Aterriza en un outbox duradero dentro de la misma transacción, y un despachador lo reproduce después de una caída del broker. Nada se pierde por un reinicio del broker.
La emisión ocurre después del commit y nunca hace fallar el trabajo. Un problema de publicación no convierte un informe almacenado en uno con error.
El sobre CloudEvents
Los mensajes viajan en modo binario de CloudEvents, versión 1.0. Los atributos de contexto viajan como cabeceras del mensaje.
Los mensajes se marcan como persistentes. Un despliegue de tenant único también estampa un valor de tenant, así que un mismo consumidor atiende las dos formas de despliegue con el mismo código.
Qué lleva un payload
Las claves del payload son
snake_case, a diferencia de la superficie REST en camelCase. Un cuerpo de report.finished:
artifact_object_key es la ruta del artefacto relativa al prefijo de almacenamiento de informes, con la forma <templateId>/<reportId>.<format>. Descargar un informe es la vía admitida para obtener el archivo, y sirve un informe en estado Finished. Despliegue muestra dónde queda ese prefijo dentro del bucket.
report.partial añade section_failures y failed_section_count junto a los mismos campos de artefacto, para que un consumidor pueda encaminar un informe utilizable pero incompleto de forma distinta a uno limpio.
report.errored sustituye los campos de artefacto por error_code y error_summary. Ambos vienen de un vocabulario fijo — report_generation_failed, report_generation_timeout o report_generation_canceled —, cada uno emparejado con un resumen fijo. El texto de error en bruto nunca viaja por el cable, así que un payload no puede filtrar una consulta, una cadena de conexión ni datos de tenant. Ramifica tu lógica según error_code.
Habilitar la publicación de eventos
La publicación de eventos es una decisión de despliegue, que se toma con
STREAMING_ENABLED. Enciéndela y Reporter exige tres ajustes más al arrancar:
Reporter se niega a arrancar cuando la publicación está encendida y cualquiera de los tres está en blanco, así que un despliegue mal configurado falla al arrancar en lugar de perder eventos en silencio.
Próximos pasos
API REST de Reporter
Las 23 operaciones, la autenticación, la paginación y los errores.
Referencia de API
La operación de manifiesto de streaming, con su formato de respuesta completo.
Variables de entorno
Cada ajuste detrás de las superficies de streaming, exchange y modo de ejecución.
¿Qué es Reporter?
Plantillas, informes, plazos y dónde encajan.