GET /v1/reports/{id} para averiguarlo.
GET /v1/streaming/events describe el contrato en formato legible por máquina. Esta página cubre el lado del consumidor: qué te dice el manifiesto, qué llega por el cable y qué transporta cada evento.
La operación de manifiesto
Streaming events devuelve el catálogo estático de eventos. Requiere autenticación como cualquier otra operación. Responde con
Cache-Control: no-store, y responde independientemente de si este despliegue publica eventos o no. Léelo al arrancar para confirmar que tu consumidor y Reporter coinciden en el contrato.
La respuesta expone la identidad de la aplicación y el catálogo:
Enrutamiento del broker
El manifiesto no revela un tema ni la topología del broker. Vincula tu cola al exchange nombrado por
RABBITMQ_REPORT_EVENTS_EXCHANGE. Cada mensaje usa la clave de la definición de evento tal cual como su routing key de AMQP: report.finished, deadline.delivery_reverted, guiones bajos incluidos.
El catálogo de eventos
Existen doce definiciones de evento entre los dos modos de ejecución.
Este canal es solo de publicación. Reporter emite estos eventos y no consume ninguno de ellos.
Entrega
Todo evento del manifiesto tiene la clase
fact. El perfil de entrega de la tabla anterior selecciona su política de entrega.
Por lo tanto, un evento con el perfil de entrega
Critical nunca se publica directamente al broker. Reporter lo escribe en el outbox de streaming durable de Mongo después del commit del estado de negocio, y un dispatcher lo reproduce tras una interrupción del broker.
La escritura del estado y la inserción en el outbox son operaciones separadas, no una única transacción atómica de aplicación. Ese hueco es una ventana de falla: una caída o una inserción fallida en el outbox después del commit del estado pierde el evento. Ninguna conciliación lo recupera. La pérdida deja solo un registro de error y una métrica. Una vez que la fila está en el outbox, el dispatcher reintenta hasta lograr la entrega.
La política solicita manejo de dead-letter para las fallas enrutables, pero las rutas actuales de RabbitMQ no proveen un destino explícito de DLQ. Esa falla se expone y se registra, sin ninguna copia forense en dead-letter.
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 envelope de CloudEvents
Los mensajes viajan en modo binario de CloudEvents, versión 1.0. Los atributos de contexto viajan como headers del mensaje.
Reporter marca los mensajes como persistentes. Un despliegue de un solo tenant igual estampa un valor de tenant, de modo que un consumidor maneja ambas formas de despliegue con el mismo código.
Qué transporta 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 clave de objeto exacta que informa el almacenamiento después de la escritura, no una ruta que los consumidores deban reconstruir. En modo de un solo tenant tiene la forma reports/<templateId>/<reportId>.<format>. El modo multi-tenant antepone el mismo camino con el segmento de tenant. Usa el valor tal cual.
Si validas su segmento de tenant, compáralo con el tenant vinculado a tu suscripción autenticada, no con otro campo del mismo mensaje. Una clave vacía en report.finished o report.partial es una violación del contrato. Descargar un informe sigue siendo la forma admitida de obtener un informe en estado Finished.
report.partial agrega section_failures y failed_section_count junto a los mismos campos de artefacto. Una clave resoluble no significa que el informe esté completo. Enruta la entrega regulatoria solo desde report.finished, y decodifica estrictamente el campo status en lugar de usar la presencia de la clave como discriminador.
report.errored reemplaza los campos de artefacto por error_code y error_summary. Que le falte un campo de artefacto no demuestra que no se escribió ningún objeto: el almacenamiento puede tener éxito antes de que falle la persistencia del estado terminal, dejando un objeto que ningún evento nombra. Ambos campos de error provienen de un vocabulario fijo: report_generation_failed, report_generation_timeout o report_generation_canceled. Cada código tiene un resumen fijo. El texto de error crudo nunca viaja por el cable, de modo que un payload no puede filtrar una consulta, una cadena de conexión ni datos de tenant. Ramifica la 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 configura con
STREAMING_ENABLED. Actívala y Reporter exige tres ajustes más al arrancar:
Cuando la publicación está apagada,
STREAMING_CLOUDEVENTS_SOURCE puede quedar sin definir. Si está definido, igual debe ser exactamente reporter. Reporter rechaza cualquier otro valor no vacío al arrancar aun con la publicación apagada. Cuando la publicación está encendida, Reporter también se niega a arrancar si alguno de los tres ajustes está en blanco, de modo que un despliegue mal configurado falla al arrancar en lugar de descartar eventos en silencio.
Próximos pasos
API REST de Reporter
Las 28 operaciones, la autenticación, la paginación y los errores.
Referencia de API
La operación de manifiesto de streaming, con la forma completa de su respuesta.
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.