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

Add request IDs and include them in every log line

Aperta
  • Qualcosa non va?
#200 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
fastapi, python
Ambito
api, authentication, backend, documentation, observability, testing

Direzione di ricerca

Read CONTRIBUTING.md first, then inspect middleware and logging setup in app/app.py, request handling in app/pesu.py, and the README. Check how FastAPI middleware ordering and asyncio.create_task context propagation work before implementing the specified request-ID behavior. Done means the listed header, validation, logging, concurrency, error-response, README, and coverage tests pass; wait for assignment before starting.

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

Descrizione

api enhancement

🔄 Updated for v5.0.0 (2026-10-08). Still open. The only change is in the background: 5.0.0 (#241) removed the CSRF prefetch, so the note about background tasks inheriting the request ID now refers to the client close.

Summary

When a caller reports "my login failed at 10:42", there's no reliable way to find their request in the logs. Lines from concurrent requests interleave, and nothing ties them together. Give every request an ID: accept one from the caller or the proxy, or generate one; put it on every log line written while handling that request; and return it in an X-Request-ID response header, so a caller can quote it in a bug report.

Background

  • Logging is configured in main() (app/app.py) with logging.basicConfig(format="%(asctime)s - %(levelname)s - %(filename)s:%(funcName)s:%(lineno)d - %(message)s").
  • One login writes several lines across app/app.py and app/pesu.py ("Authenticating user=…", "Connecting to PESU Academy…", "Login successful…"), and many requests run concurrently on one event loop.
  • Since 5.0.0 a request starts no background work of its own. The one task that can outlive it, the client close in _close_client_quietly (app/pesu.py, via asyncio.ensure_future), copies the current contextvars context, so its log line would inherit the request's ID automatically. That's useful, but say so in a comment.

Proposed change

  1. Middleware (app/request_id.py or similar, registered in app/app.py):
    • Use the incoming X-Request-ID if it's present and safe: at most 128 characters, matching [A-Za-z0-9._-]+. Anything else is ignored and replaced; the value ends up in logs, so it must not allow log injection (for example newlines).
    • Otherwise generate one with uuid.uuid4().hex.
    • Check on staging whether Render's proxy adds its own request ID header, and prefer it if it does (write down what you find in the PR).
    • Store the ID in a contextvars.ContextVar, and set X-Request-ID on the response.
  2. Logging: a logging.Filter that adds record.request_id (or - outside a request), attached in main(), with %(request_id)s added to the format. Coordinate with #201, which changes the log format, so the two don't conflict.
  3. Ordering with the metrics middleware: the request ID should be set before anything logs. Check the order in which FastAPI applies @app.middleware decorators (the last one registered runs first), and comment on the choice.
  4. Document the header in the README (for callers: "quote this ID when reporting a problem").

Tests

  • A valid incoming ID is echoed back, and a missing, too-long or unsafe one is replaced with a generated one.
  • Log records written during a request carry the ID (caplog), and records outside a request get -.
  • Two concurrent requests get different IDs, and their log lines don't mix (use asyncio.gather with the app).
  • Error responses (400, 401, 502) also carry the header.

Acceptance criteria

  • Every response has X-Request-ID, and every log line written during a request contains it
  • Caller-supplied IDs are validated
  • README updated

How to contribute

  • Wait until you're assigned. Comment to ask for this issue, then wait for a maintainer to assign it to you before writing any code. PRs for unassigned issues are closed without review.
  • Read CONTRIBUTING.md first. It covers forking, setting up with uv, and running the tests.
  • Branch from dev in your fork, and open the PR against dev with a Conventional Commit title and Closes #200 in the description.
  • Bump the minor version in pyproject.toml and run uv lock (CI checks this). uv run pre-commit run --all-files must pass, and coverage must stay at 100%.
  • Update the README, app/docs/ and comments in the same PR as the behaviour they describe.
  • Never log, print, store or echo a password or token, including in tests, PR descriptions and screenshots.
Lingua principale
Python
Stelle
22
Fork
29
Merge medio
1g 3h
PR unite (30g)
19

Preparare l'ambiente

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 pesu-dev/auth

Tutte le issue di pesu-dev/auth

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.