Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Propagate the request correlation id to downstream sinks

Aperta
  • Qualcosa non va?
#212 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
aws, kafka, python
Ambito
backend

Direzione di ricerca

Leggi prima src/utils/observability.py per confermare come vengono risolti gli ID di correlazione, quindi traccia il percorso della chiamata in HandlerTopic._write_to_all() fino a WriterKafka.write() e WriterEventBridge.write(). Implementa la propagazione esclusivamente tramite i metadati di trasporto (header Kafka o detail/TraceHeader di EventBridge) e mantieni il comportamento in assenza di ID. Esegui o aggiungi unit test con e senza ID di correlazione e verifiche di integrazione per i metadati del sink, quindi aggiorna la sezione "Logging & Correlation" del README per documentare il contratto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement
Feature Description

Propagate the request correlation id to the downstream sinks, so consumers of the fan-out targets can join their processing logs to the EventGate request that produced the message:

  • Kafka — add the id as a record header (e.g. correlation_id) in WriterKafka.write(). Record headers keep the payload untouched, and consumers can read the header without schema changes.
  • EventBridge — include the id in the put_events entry, either as a top-level field of Detail or via TraceHeader, in WriterEventBridge.write().
  • Postgres — optional; would require a schema change (extra column), so likely out of scope for the first iteration.
Problem / Opportunity

Since #193 / PR #204, every EventGate request resolves a correlation id (X-Correlation-ID → X-Request-ID → API Gateway request id), logs it on every line and returns it in the X-Correlation-ID response header. The id currently stops at EventGate: once a message is fanned out, downstream consumers have no way to correlate their processing with the originating request.

Beneficiaries: teams consuming the Kafka topics and EventBridge events, and anyone debugging a cross-system flow end-to-end — one id would then trace a message from the caller, through EventGate's logs, into every sink's consumer logs.

Acceptance Criteria
  1. A message published to Kafka carries the request's correlation id as a record header; the message payload (value) is byte-for-byte unchanged.
  2. An event published to EventBridge carries the request's correlation id in its entry metadata (TraceHeader or a documented Detail field); the schema-validated payload is unchanged.
  3. When no correlation id is resolved (empty id), no header/field is added and writes behave exactly as today.
  4. Existing topic schema validation and all existing consumers are unaffected — propagation uses transport metadata only, never the message body.
  5. Unit tests cover both writers with and without a bound correlation id; integration tests prove the header/field arrives in the sink.
  6. README "Logging & Correlation" documents the downstream propagation contract.
Proposed Solution

The writers do not currently receive the correlation id; it is bound in src/utils/observability.py. Two options:

  • a small accessor (e.g. current_correlation_id()) in src/utils/observability.py, read by the writers, or
  • an explicit parameter threaded through HandlerTopic._write_to_all() into Writer.write().

The explicit parameter is more testable and keeps writers free of hidden state; the accessor avoids touching the Writer interface. Alternative considered and rejected: putting the id into the message body — breaks topic schema validation and changes consumer contracts.

The id is already validated against ^[A-Za-z0-9._:-]{1,128}$ before use, so it is safe to forward verbatim.

Dependencies / Related
  • #193 (structured logging + correlation id)
  • PR #204 (implementation; ADR adr/001-observability/001-observability.md)
Additional Context

Follow-up proposed during the second-opinion review of PR #204 (item P7). Postgres propagation can be a separate issue if a schema change is ever justified.

Lingua principale
Python
Stelle
4
Fork
0
Merge medio
1g 20h
PR unite (30g)
8

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

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/EventGate

Tutte le issue di AbsaOSS/EventGate

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.