Correlate HTTP requests with scenarios and X-Ray, including embedded fragments

Abierto
  • ¿Algo no está bien?
#28 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 6 días

@fateeand ya está trabajando en esto.

Desde el 27/10/2026.

  • #29 de @fateeand — abierto

Evaluación

Este issue todavía no se ha evaluado.

Descripción

enhancement

Problem

Backend logs and AWS X-Ray traces can't be tied to the user journeys the library records:

  1. No scenario id attached to the backend requests. A scenario's id links its RUM record, BI events and client logs, but requests made during the scenario carry nothing the backend can log or search by.
  2. Relative URLs get no X-Ray header. The RUM client checks its X-Ray rule against the URL exactly as the app passes it. Angular HttpClient passes relative URLs (/api/...), but the library's default rule only matches absolute same-origin URLs. So most HttpClient requests go out without X-Amzn-Trace-Id, even in a single app, and the backend can't continue the browser's trace.
  3. Fragment requests aren't traced at all. In a micro-frontend page, the RUM client runs only in the shell and patches only the shell's fetch and XMLHttpRequest. Each fragment (e.g. Web Fragments) runs in its own hidden iframe with its own copies of these, so its requests get no X-Ray header and no RUM HTTP events.

Proposed change

  • Scenario header. Add uwtScenarioHeaderInterceptor() and uwtScenarioContext(scenario). A request marked with a scenario gets an X-Uwt-Scenario-Id: <scenario.id> header; apps can rename it with { headerName }. Requests are marked one by one, because several scenarios can run at once and nothing else can tell which one a request belongs to. The header is sent only on same-origin requests, only while telemetry is on, and never on unmarked requests. The interceptor only adds the header: settling the scenario stays with the caller or traceScenario.
  • Relative URLs. Treat relative URLs as same-origin in the default http telemetry config.
  • Fragments. Let the shell's RUM sink trace fragments. At startup, a fragment's 'broadcast' sink hands its window to the shell, and the shell applies the RUM client's own fetch/XHR plugins to it. The fragment keeps its own fetch, XHR and zone.js. The shell lets go of the window when the fragment is removed or destroyed.
  • Backend convention (documented). The backend logs the header as scenarioId and adds it to its X-Ray trace as the scenarioId annotation, so annotation.scenarioId = "<id>" finds every trace of a journey.

Acceptance criteria

  • Marked same-origin requests carry X-Uwt-Scenario-Id. Unmarked requests, cross-origin requests, requests made while telemetry is off and server-side requests don't.
  • Concurrent scenarios each send their own id, and a retried request sends the same id again.
  • Same-origin requests with relative URLs carry X-Amzn-Trace-Id; cross-origin requests still don't.
  • Requests from a fragment using provideUwtTelemetrySink('broadcast') carry X-Amzn-Trace-Id, with both the fetch and XHR backends.
  • Those requests appear as RUM HTTP and X-Ray events in the shell's session.
  • A removed fragment is unpatched and not kept in memory by the shell.
  • DESIGN.md and the README describe the behaviour, the backend convention and the limits.

Notes

  • New public API: uwtScenarioHeaderInterceptor, uwtScenarioContext, UwtScenarioHeaderOptions and UWT_DEFAULT_SCENARIO_HEADER. The X-Ray changes need no changes in consumer apps.
  • Fragment requests count against the shared session's event budget (200 by default), the same as the shell's.
  • Requests made before the shell's RUM client loads aren't traced, the same as in the shell today.
  • Apps that pass their own telemetries config keep their own X-Ray rule.
Lenguaje dominante
TypeScript
Estrellas
0
Forks
0
Merge medio
5 d 6 h
PR fusionados (30 d)
14

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de AbsaOSS/ui-watchtower

Todos los issues de AbsaOSS/ui-watchtower

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.