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

Aperta
  • Qualcosa non va?
#28 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

@fateeand ci sta già lavorando.

Dal 27/10/2026.

  • #29 di @fateeand — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.
Lingua principale
TypeScript
Stelle
0
Fork
0
Merge medio
4g 8h
PR unite (30g)
17

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di AbsaOSS/ui-watchtower

Tutte le issue di AbsaOSS/ui-watchtower

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.