exis_ray 0.5.7 → 0.5.8

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: fa3229011d1a59fbd0d65ec137d7a5223f70bd3c3f69add47c27bc965a3e62f1
-  data.tar.gz: f08f78169685640fc2c6f1dbfb51c5e64826e4e776c4c1b66ee5d4196592697d
+  metadata.gz: 327a3ed9c5558bba99acba81d3a3b328a271c16f4725c88a435f08ea8b1526a8
+  data.tar.gz: 661cf580101b617b50b565ec342f8a09d8da5a4b8c4d8c11163ea5000236a64e
 SHA512:
-  metadata.gz: cc5941334d4f7a7241ba6629d5e27f08ac93ce6e704aaa31b90868a5353ff92143795b3b21cb6426d6b47172fa457de3e834899212b9b8ef1a8b28c4a1d81895
-  data.tar.gz: 3d9113cc7e2ed5790723290ff9c635b15bb8d4ec6b649c55cf3aab406a8e12d3598dff59d2f2c12d310d256a3f535fda4f816ee66d196e752c5ffb9e8d9d33e3
+  metadata.gz: d23f08bf5951c9efa611c09a2ba3654ae8763b5bff0e4706ae68f540f52f3668b0c8b6f9bb4c076ba9ad6aff05df50de40f3d0c2e1b69ebd0aaafed6dcdafce2
+  data.tar.gz: 9514884ededf873b309345eee8d6e217c6b16b49ba194b55d68825f8a544d907da6d6d624a620223653249da21c12a91de1efe235bb4e39ea5f97c95be15d11d

data/CHANGELOG.md

@@ -1,3 +1,16 @@
+## [0.5.8] - 2026-03-31
+
+### Added
+- **`ExisRay::BugBunny::ConsumerTracingMiddleware`:** Nuevo middleware para el consumer stack de BugBunny. Corre antes de que la gema procese cada mensaje (antes de `consumer.message_received`), garantizando que todos los logs internos de BugBunny — `consumer.message_received`, `consumer.route_matched`, `consumer.rpc_reply`, `consumer.message_processed` — incluyan `root_id`, `trace_id` y `source`. Si el mensaje no trae header de traza, genera un `root_id` nuevo automáticamente.
+- **Propagación RPC bidireccional:** El `Railtie` registra automáticamente dos callbacks en BugBunny: `rpc_reply_headers` inyecta el trace header actualizado (`Self`, `TotalTimeSoFar`, `CalledFrom`) en el reply del consumer; `on_rpc_reply` hidrata el tracer en el thread del publisher al recibir la respuesta, permitiendo que `producer.rpc_response_received` y `request_complete` reflejen el viaje completo por el ecosistema de microservicios.
+
+### Changed
+- **BugBunny auto-instrumentado:** La integración BugBunny se mueve al `after_initialize` del `Railtie`, resolviendo el problema de orden de carga. Con ambas gemas en el `Gemfile`, todo se configura automáticamente sin intervención del desarrollador.
+- **MANIFEST.md:** Documentación completa del estándar de observabilidad: semántica de niveles de log, block form obligatorio para DEBUG, medición de duraciones con reloj monotónico, filtrado de claves sensibles, resiliencia del logger, y tabla completa de campos auto-inyectados con condiciones de activación.
+
+### Removed
+- **`ExisRay::BugBunny::ConsumerTracing`:** Concern eliminado. Reemplazado por `ConsumerTracingMiddleware` que cubre el ciclo completo del mensaje, no solo el action del controller.
+
 ## [0.5.7] - 2026-03-27
 
 ### Fixed

data/MANIFEST.md

@@ -5,81 +5,185 @@ Este documento define el estándar obligatorio de telemetría y logging estructu
 ## Objetivo
 Transformar el logging tradicional en un **flujo de eventos de datos**. Esto permite que herramientas de análisis puedan generar dashboards de rendimiento, alertas inteligentes y rastreo de errores sin necesidad de procesamiento manual de texto o transformaciones complejas.
 
+---
+
 ## Reglas Fundamentales
 
-### 1. Unidad en la Key, Número en el Valor (Data First)
-La regla de oro para que las métricas sean operables es separar la unidad del dato numérico. **Nunca** incluir unidades dentro de los valores de los logs.
-*   Incorrecto: `duration="0.5s"`, `memory="128MB"`.
-*   Correcto: `duration_s=0.5`, `memory_mb=128`.
+### 1. Formato de Mensaje
+
+Todo log debe emitirse como una línea de pares `key=value` en el siguiente orden:
+
+```
+component=x event=y [campos adicionales]
+```
+
+- `component`: nombre de la gema, librería o módulo responsable (ej: `exis_ray`, `storage_engine`). Siempre en `snake_case`.
+- `event`: nombre puntual de la acción o hito (ej: `http_request`, `sync_complete`). Siempre en `snake_case`.
+- Los campos adicionales van a continuación, en cualquier orden.
+
+Valores con espacios deben ir entre comillas dobles: `error_message="Server reset connection"`.
+
+### 2. Niveles de Log
+
+Cada nivel tiene una semántica estricta. Usar el nivel incorrecto es un error.
+
+| Nivel   | Cuándo usarlo |
+| :------ | :------------ |
+| `ERROR` | Se lanzó una excepción o el sistema no pudo completar una operación crítica. |
+| `WARN`  | Ocurrió algo inesperado pero la ejecución continuó. |
+| `INFO`  | Flujo normal del sistema. Eventos relevantes para el negocio u operaciones. |
+| `DEBUG` | Detalle técnico interno. Solo útil durante desarrollo o diagnóstico. |
+
+**Regla de DEBUG:** Siempre usar block form para evitar interpolación innecesaria:
+```ruby
+# Correcto
+logger.debug { "component=cache event=miss key=#{key}" }
+
+# Incorrecto — evalúa la interpolación aunque DEBUG esté desactivado
+logger.debug "component=cache event=miss key=#{key}"
+```
+
+**Prohibido:** Nunca usar `Kernel#warn` ni escribir directamente a `$stderr`. Todo output debe ir por el logger configurado.
+
+### 3. Unidad en la Key, Número en el Valor (Data First)
+
+La regla de oro para que las métricas sean operables es separar la unidad del dato numérico. **Nunca** incluir unidades dentro de los valores.
+
+```
+# Incorrecto
+duration="0.5s"   memory="128MB"
+
+# Correcto
+duration_s=0.5    memory_mb=128
+```
 
-**Sufijos de unidad recomendados:**
-- `_s`: Segundos (Float). Estándar para duraciones y latencias visibles al negocio.
+**Sufijos de unidad:**
+- `_s`: Segundos (Float). Estándar para duraciones y latencias.
 - `_ms`: Milisegundos (Integer). Para precisión técnica interna de alta frecuencia.
 - `_count`: Cantidades o volúmenes (Integer). Ej: `record_count`, `retry_count`.
 - `_bytes` / `_kb` / `_mb`: Unidades de almacenamiento o memoria.
-- `_human`: (Opcional) Texto explicativo legible para humanos (ej: `duration_human="2 hours"`).
+- `_human`: (Opcional) Texto legible para humanos. Ej: `duration_human="2 minutes 5 seconds"`.
+
+### 4. Medición de Duraciones
+
+Las duraciones **siempre** deben medirse con reloj monotónico. Nunca con `Time.now` (susceptible a saltos de reloj del sistema).
+
+```ruby
+# Correcto
+start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
+# ... operación ...
+duration_s = Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
+
+# Incorrecto
+start = Time.now
+duration_s = Time.now - start
+```
+
+### 5. Source: Entrypoint de Ejecución
 
-### 2. Contexto de Identidad
-Cada línea de log debe llevar los metadatos necesarios para identificar su origen técnico de forma inmediata:
-*   `component`: Nombre de la gema, librería o módulo responsable (ej: `exis_ray`, `storage_engine`).
-*   `event`: Nombre de la acción puntual o hito alcanzado (ej: `http_request`, `engine.complete`).
-*   `source`: El punto de entrada de la ejecución (`http`, `sidekiq`, `task`, `system`).
+El campo `source` identifica el punto de entrada del proceso. Es obligatorio y solo acepta estos valores:
 
-### 3. Convenciones de Naming & Tipos
-- **Naming:** Las llaves (keys) deben usar siempre `snake_case`. Para campos estándar, se prefiere seguir las **OpenTelemetry Semantic Conventions**.
-- **Valores Numéricos:** Deben emitirse como números reales (sin sufijos de texto) para permitir que el motor de logs realice el casting automático.
-- **Formato:** Pares `key=value` en una sola línea estructurada.
+| Valor      | Cuándo usarlo |
+| :--------- | :------------ |
+| `http`     | Request HTTP entrante (procesado por Rack/Rails). |
+| `sidekiq`  | Job procesado por Sidekiq. |
+| `task`     | Tarea programada o proceso de larga duración (Rake, Cron, TaskMonitor). |
+| `system`   | Ejecución iniciada por otro sistema interno (ej: consumidor RabbitMQ/BugBunny). |
+
+`source` es inyectado automáticamente por el middleware correspondiente. **No lo incluyas manualmente.**
+
+### 6. Seguridad y Privacidad
+
+**Filtrado de claves sensibles:** Cualquier campo cuya key coincida con el patrón `password|pass|passwd|secret|token|api_key|auth` debe reemplazar su valor por `[FILTERED]`. Esto es aplicado automáticamente por `ExisRay::JsonFormatter` en todos los logs.
+
+**Sin PII:** Nunca loguear datos crudos de usuarios. Solo se permiten identificadores: `user_id`, `isp_id`.
+
+```
+# Incorrecto
+component=auth event=login email=user@example.com password=abc123
+
+# Correcto
+component=auth event=login user_id=42 password=[FILTERED]
+```
+
+### 7. Resiliencia del Logger
+
+Un fallo en el logging nunca debe interrumpir el flujo principal de la aplicación. Toda operación de logging debe estar protegida:
+
+```ruby
+# Correcto
+begin
+  logger.info "component=sync event=complete duration_s=#{duration_s}"
+rescue StandardError
+  # silenciar — el log es accesorio, no crítico
+end
+```
+
+### 8. Convenciones de Naming
+
+- Keys siempre en `snake_case`.
+- Valores numéricos emitidos como números reales (sin comillas) para que el motor de logs realice casting automático.
+- Para campos estándar, seguir las **OpenTelemetry Semantic Conventions** donde sea posible.
+
+---
 
 ## 🔭 Alineación con OpenTelemetry
 
-Para garantizar la interoperabilidad, `exis_ray` sigue el **OpenTelemetry Log Data Model**. Siempre que sea posible, los campos deben mapearse a las convenciones semánticas oficiales:
+`exis_ray` sigue el **OpenTelemetry Log Data Model**. Los campos se mapean a las convenciones semánticas oficiales:
 
-| Campo ExisRay | OTel Semantic Convention | Descripción |
-| :--- | :--- | :--- |
-| `body` | `body` | El contenido principal del log. |
-| `level` | `severity_text` | Nivel de importancia. |
-| `duration_s` | `duration` (en segundos) | Tiempo de ejecución. |
-| `method` | `http.request.method` | Método HTTP. |
-| `status` | `http.response.status_code` | Código de respuesta. |
-| `path` | `url.path` | Ruta del request. |
-| `user_id` | `user.id` | Identificador del usuario. |
+| Campo ExisRay  | OTel Semantic Convention    | Descripción              |
+| :------------- | :-------------------------- | :----------------------- |
+| `body`         | `body`                      | Contenido principal del log (texto libre). |
+| `level`        | `severity_text`             | Nivel de importancia.    |
+| `duration_s`   | `duration` (en segundos)    | Tiempo de ejecución.     |
+| `method`       | `http.request.method`       | Método HTTP.             |
+| `status`       | `http.response.status_code` | Código de respuesta HTTP.|
+| `path`         | `url.path`                  | Ruta del request.        |
+| `user_id`      | `user.id`                   | Identificador del usuario.|
 
-## 🏗 Infraestructura de Datos (Automática)
+---
 
-Para evitar logs redundantes y pesados, **NUNCA** incluyas manualmente las siguientes llaves en tus mensajes de log. La capa de infraestructura (`exis_ray`) las inyecta automáticamente en el nivel raíz del JSON:
+## 🏗 Campos Auto-Inyectados por ExisRay
 
-| Llave | Descripción | Por qué no incluirla |
-| :--- | :--- | :--- |
-| `time` | Timestamp ISO8601 | Lo añade el Logger base. |
-| `level` | INFO, ERROR, etc. | Lo añade el Logger base. |
-| `service` | Nombre de la App | Se obtiene de la configuración global. |
-| `source` | Entrypoint (http, task) | Lo inyecta el middleware/monitor correspondiente. |
-| `root_id` | Trace ID (AWS X-Ray) | Se gestiona a nivel de hilo/petición. |
-| `correlation_id`| ID de rastreo cruzado | Se genera automáticamente al inicio de la ejecución. |
-| `user_id` / `isp_id`| Contexto de negocio | Se extrae del estado global de la petición. |
-| `sidekiq_job` | Clase del Worker | Inyectado automáticamente en procesos Sidekiq. |
-| `task` | Nombre de la tarea | Inyectado automáticamente por el TaskMonitor. |
+**NUNCA** incluyas manualmente los siguientes campos. `ExisRay::JsonFormatter` los inyecta automáticamente en cada línea de log:
 
-> **Regla de Oro:** Tu log manual solo debe contener datos de **tu lógica de negocio**. La infraestructura ya sabe quién eres, de dónde vienes y cuál es tu ID de traza.
+| Campo            | Descripción                        | Condición                                      |
+| :--------------- | :--------------------------------- | :--------------------------------------------- |
+| `time`           | Timestamp ISO8601 UTC              | Siempre                                        |
+| `level`          | Nivel de severidad                 | Siempre                                        |
+| `service`        | Nombre de la aplicación            | Siempre                                        |
+| `root_id`        | Trace ID raíz (AWS X-Ray)          | Cuando hay trace context activo                |
+| `trace_id`       | Trace ID completo (formato X-Ray)  | Cuando hay trace context activo                |
+| `source`         | Entrypoint de ejecución            | Cuando hay trace context activo                |
+| `correlation_id` | ID de rastreo cruzado              | Cuando `Current.correlation_id` está presente  |
+| `user_id`        | ID del usuario autenticado         | Cuando `Current.user_id` está presente         |
+| `isp_id`         | ID del ISP                         | Cuando `Current.isp_id` está presente          |
+| `sidekiq_job`    | Clase del Worker Sidekiq           | Solo en procesos Sidekiq                       |
+| `task`           | Nombre de la tarea                 | Solo en procesos TaskMonitor                   |
+| `tags`           | Tags de Rails TaggedLogging        | Solo si hay tags activos en el hilo            |
+
+> **Regla de Oro:** Tu log manual solo debe contener datos de **tu lógica de negocio**. La infraestructura ya sabe quién eres, de dónde venís y cuál es tu ID de traza.
 
 ---
 
 ## 🛰 Ciclo de Vida del Evento
 
-## Ciclo de Vida del Evento
-
 ### Procesos, Trabajos y Tareas (Jobs/Tasks)
+
 Todo proceso aislado debe reportar su inicio y su finalización con una estructura consistente:
+
 - `event`: Identificador de estado (ej: `task_started`, `task_finished`).
-- `status`: Resultado final de la operación (`success`, `failed`, `aborted`). En contexto de tareas/jobs, siempre es un string semántico, no un código HTTP.
-- `duration_s`: Tiempo total de ejecución (calculado con reloj monotónico).
+- `status`: Resultado final (`success`, `failed`, `aborted`). Siempre string semántico, nunca código HTTP.
+- `duration_s`: Tiempo total de ejecución (reloj monotónico).
 - `error_class` / `error_message`: Obligatorios solo en caso de fallo.
 
-### Peticiones de Interfaz (APIs/HTTP)
-Los logs de cierre de peticiones deben estandarizar el reporte de rendimiento para telemetría:
-- `status`: Código de respuesta HTTP (Integer). En contexto HTTP siempre es el código numérico (ej: `200`, `404`, `500`).
+### Peticiones HTTP
+
+Los logs de cierre de petición deben estandarizar el reporte de rendimiento:
+
+- `status`: Código HTTP (Integer). Ej: `200`, `404`, `500`.
 - `duration_s`: Tiempo total de respuesta del servidor.
-- `[subsystem]_runtime_s`: Desglose opcional de tiempos por capa (ej: `db_runtime_s`, `view_runtime_s`).
+- `[subsystem]_runtime_s`: Desglose opcional por capa (ej: `db_runtime_s`, `view_runtime_s`).
 
 ---
 
@@ -87,26 +191,32 @@ Los logs de cierre de peticiones deben estandarizar el reporte de rendimiento pa
 
 **En el código fuente:**
 ```ruby
-# Reporte de éxito con métricas integradas
-logger.info "component=data_processor event=sync_complete status=success duration_s=1.25 record_count=500"
+start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
+# ... operación ...
+duration_s = Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
 
-# Reporte de error con contexto técnico
-logger.error "component=data_processor event=sync_complete status=failed error_class=Timeout error_message=\"Server reset\""
+logger.info "component=data_processor event=sync_complete status=success duration_s=#{duration_s} record_count=500"
+
+# En caso de error:
+rescue => e
+  logger.error "component=data_processor event=sync_complete status=failed error_class=#{e.class} error_message=\"#{e.message}\""
+end
 ```
 
-**Resultado JSON unificado:**
+**Resultado JSON unificado (emitido por ExisRay):**
 ```json
 {
   "time": "2026-03-24T14:00:00Z",
   "level": "INFO",
   "service": "my_application",
+  "root_id": "1-abc123",
+  "trace_id": "Root=1-abc123",
+  "source": "task",
+  "correlation_id": "my_application;1-abc123",
   "component": "data_processor",
   "event": "sync_complete",
   "status": "success",
   "duration_s": 1.25,
-  "record_count": 500,
-  "source": "task",
-  "root_id": "Root=1-...",
-  "correlation_id": "my_application;Root=..."
+  "record_count": 500
 }
 ```

data/lib/exis_ray/bug_bunny/consumer_tracing_middleware.rb

@@ -0,0 +1,56 @@
+# frozen_string_literal: true
+
+module ExisRay
+  module BugBunny
+    # Consumer middleware para BugBunny que establece el trace context de ExisRay
+    # antes de que la gema empiece a procesar el mensaje.
+    #
+    # Al correr en el consumer middleware stack (antes de `consumer.message_received`),
+    # garantiza que **todos** los logs internos de BugBunny y del controller action
+    # incluyan `root_id`, `trace_id` y `source`.
+    #
+    # Se registra automáticamente al cargar ExisRay con BugBunny presente.
+    # El usuario final no necesita configuración adicional.
+    #
+    # @example Registro automático (ocurre en Railtie#after_initialize)
+    #   BugBunny.consumer_middlewares.use ExisRay::BugBunny::ConsumerTracingMiddleware
+    class ConsumerTracingMiddleware < ::BugBunny::ConsumerMiddleware::Base
+      # Inyecta el trace context antes de delegar al siguiente middleware.
+      # Limpia el contexto en `ensure` para no contaminar el próximo mensaje.
+      #
+      # @param delivery_info [Bunny::DeliveryInfo]
+      # @param properties    [Bunny::MessageProperties]
+      # @param body          [String]
+      def call(delivery_info, properties, body)
+        setup_trace_context(properties)
+        @app.call(delivery_info, properties, body)
+      ensure
+        ExisRay::Tracer.reset rescue nil
+      end
+
+      private
+
+      # Hidrata el Tracer con el header de traza del mensaje entrante.
+      # Si no hay header (mensaje publicado sin trace context), genera un root_id nuevo
+      # para que los logs siempre tengan contexto de trazabilidad.
+      #
+      # @param properties [Bunny::MessageProperties]
+      # @return [void]
+      def setup_trace_context(properties)
+        trace_header = properties.headers&.[](ExisRay.configuration.propagation_trace_header)
+
+        if trace_header.present?
+          ExisRay::Tracer.hydrate(trace_id: trace_header, source: 'system')
+        else
+          ExisRay::Tracer.created_at = Process.clock_gettime(Process::CLOCK_MONOTONIC)
+          ExisRay::Tracer.source     = 'system'
+          ExisRay::Tracer.root_id    = ExisRay::Tracer.send(:generate_new_root)
+        end
+
+        ExisRay.sync_correlation_id
+      rescue StandardError
+        # El tracing nunca debe interrumpir el procesamiento del mensaje.
+      end
+    end
+  end
+end

data/lib/exis_ray/railtie.rb

@@ -44,6 +44,31 @@ module ExisRay
         log_boot("component=exis_ray event=json_logging_enabled")
       end
 
+      # --- Integración BugBunny ---
+      if defined?(::BugBunny)
+        require "exis_ray/bug_bunny/publisher_tracing"
+        require "exis_ray/bug_bunny/consumer_tracing_middleware"
+        ::BugBunny.consumer_middlewares.use ExisRay::BugBunny::ConsumerTracingMiddleware
+        ::BugBunny.configuration.rpc_reply_headers = lambda {
+          next {} unless ExisRay::Tracer.root_id.present?
+
+          { ExisRay.configuration.propagation_trace_header => ExisRay::Tracer.generate_trace_header }
+        }
+        ::BugBunny.configuration.on_rpc_reply = lambda { |headers|
+          begin
+            trace_header = headers&.[](ExisRay.configuration.propagation_trace_header)
+            next unless trace_header.present?
+
+            # Solo actualizamos trace_id — no tocamos created_at ni source del publisher.
+            ExisRay::Tracer.trace_id = trace_header
+            ExisRay::Tracer.parse_trace_id
+            ExisRay.sync_correlation_id
+          rescue StandardError
+          end
+        }
+        log_boot("component=exis_ray event=bug_bunny_instrumented")
+      end
+
       # --- Instrumentación de ActiveResource ---
       if defined?(ActiveResource::Base)
         require "exis_ray/active_resource_instrumentation"

data/lib/exis_ray/version.rb

@@ -2,5 +2,5 @@
 
 module ExisRay
   # Versión actual de la gema.
-  VERSION = "0.5.7"
+  VERSION = "0.5.8"
 end

data/lib/exis_ray.rb

@@ -24,13 +24,6 @@ require "exis_ray/faraday_middleware" if defined?(Faraday)
 # Solo cargamos la instrumentación si ActiveResource está presente.
 require "exis_ray/active_resource_instrumentation" if defined?(ActiveResource::Base)
 
-# Integraciones BugBunny: publisher middleware y consumer concern.
-# Solo se cargan si la gema BugBunny está presente.
-if defined?(::BugBunny)
-  require "exis_ray/bug_bunny/publisher_tracing"
-  require "exis_ray/bug_bunny/consumer_tracing"
-end
-
 # Integración automática con Rails
 # Solo cargamos el Railtie si la constante Rails está definida.
 require "exis_ray/railtie" if defined?(Rails)

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: exis_ray
 version: !ruby/object:Gem::Version
-  version: 0.5.7
+  version: 0.5.8
 platform: ruby
 authors:
 - Gabriel Edera
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2026-03-27 00:00:00.000000000 Z
+date: 2026-03-31 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activesupport
@@ -54,7 +54,7 @@ files:
 - Rakefile
 - lib/exis_ray.rb
 - lib/exis_ray/active_resource_instrumentation.rb
-- lib/exis_ray/bug_bunny/consumer_tracing.rb
+- lib/exis_ray/bug_bunny/consumer_tracing_middleware.rb
 - lib/exis_ray/bug_bunny/publisher_tracing.rb
 - lib/exis_ray/configuration.rb
 - lib/exis_ray/current.rb

data/lib/exis_ray/bug_bunny/consumer_tracing.rb

@@ -1,63 +0,0 @@
-# frozen_string_literal: true
-
-require 'active_support/concern'
-
-module ExisRay
-  module BugBunny
-    # Concern para BugBunny::Controller que restaura el trace context de ExisRay
-    # a partir del header configurado en `ExisRay.configuration.propagation_trace_header`
-    # (por defecto `'X-Amzn-Trace-Id'`) inyectado por el publicador.
-    #
-    # Permite que todos los logs emitidos durante el procesamiento de un mensaje
-    # incluyan el mismo root_id y correlation_id que el request HTTP original,
-    # logrando trazabilidad distribuida de punta a punta.
-    #
-    # El contexto se limpia siempre en `ensure`, garantizando que un error en el
-    # controller no contamine el procesamiento del siguiente mensaje.
-    #
-    # @example Incluir en el ApplicationController de BugBunny
-    #   class ApplicationController < BugBunny::Controller
-    #     include ExisRay::BugBunny::ConsumerTracing
-    #   end
-    module ConsumerTracing
-      extend ActiveSupport::Concern
-
-      # Header AMQP desde el cual se lee el trace context propagado.
-      # Debe coincidir con `propagation_trace_header` usado por el publisher.
-      def self.trace_header
-        ExisRay.configuration.propagation_trace_header
-      end
-
-      included do
-        around_action :exis_ray_trace_context
-      end
-
-      private
-
-      # Restaura el contexto de trazabilidad y lo limpia al finalizar,
-      # independientemente de si el controller levantó una excepción.
-      #
-      # @yieldreturn [void]
-      def exis_ray_trace_context
-        setup_exis_ray_context
-        yield
-      ensure
-        ExisRay::Tracer.reset rescue nil
-      end
-
-      # Hidrata el Tracer con el header de traza recibido en el mensaje.
-      # Si el header no está presente (mensaje sin trace context), no hace nada.
-      #
-      # @return [void]
-      def setup_exis_ray_context
-        trace_header = headers[self.class.trace_header]
-        return unless trace_header.present?
-
-        ExisRay::Tracer.hydrate(trace_id: trace_header, source: 'system')
-        ExisRay.sync_correlation_id
-      rescue StandardError
-        # El tracing nunca debe interrumpir el procesamiento del mensaje.
-      end
-    end
-  end
-end