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

Retry the profile call once on transient errors, never the login

Aperta
  • Qualcosa non va?
#186 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
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
authentication, backend

Direzione di ricerca

Read CONTRIBUTING.md and inspect _fetch_new_client_with_csrf_token in app/pesu.py, including its _upstream_call(self._metrics, "csrf_fetch") usage and the existing login POST path. Add tests for the listed transient and non-transient cases, metrics per attempt, client closure, and exactly one login POST. Done means the CSRF fetch retries once when appropriate, the login POST never retries, and the live suite passes with the required credentials.

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

Descrizione

authentication enhancement pesuacademy

🔄 Updated for v5.0.0 (2026-10-08). The CSRF fetch this issue was about no longer exists: 5.0.0 signs in through PESU Academy's mobile API, which needs no CSRF token (#241). The same idea now applies to the profile call, the one request that is safe to repeat, so the issue is rewritten around it. The original proposal is in the edit history.

⚠️ PES University students only. This change sits in the login path and has to be tested end to end against PESU Academy with real PESU credentials (see "Tests that need credentials" in CONTRIBUTING.md). Run the whole suite with your credentials in .env and paste the summary line into your PR. Every run makes real logins to PESU Academy, so run it when you need it, not in a loop.

Summary

A login with profile: true makes two calls to PESU Academy: the login, then the profile. If the connection drops on the profile call, the whole request fails with a 502 even though the credentials were fine and the call is safe to repeat. Retry the profile call only, once, on transient network errors. Never retry the login.

Background

  • _fetch_profile in app/pesu.py POSTs the dispatcher form (PROFILE_FORM) to DISPATCHER_URL with the access token from the login, inside _upstream_call(self._metrics, "profile_fetch"). It only reads the student's profile, so sending it twice changes nothing on PESU's side. The access token is valid for 30 minutes, far longer than a retry takes.
  • The login is _login, a POST of the credentials to LOGIN_URL (operation="login"). Repeating it would make a second login for the student: another session on PESU's side and, for a wrong password, another failed attempt against their account. It must never be retried automatically.
  • Today a transport error on the profile call becomes ProfileFetchError (502), and a non-200 response does too.

Proposed change

  1. In _fetch_profile, retry the POST once on a transient failure: httpx2.ConnectError, httpx2.ConnectTimeout, httpx2.RemoteProtocolError, or a 502/503/504 response.
    • Wait a short, jittered delay first (for example a random 200–500 ms), so many requests don't all retry at the same moment.
    • Don't retry a ReadTimeout (PESU is slow, and retrying doubles the wait), any other 4xx or 5xx, PESU's error envelope (an HTTP 200 with {"status": 403, ...}), or a response that fails to parse: those aren't transient.
  2. Each attempt is its own async with _upstream_call(...) block, so /metrics counts attempts truthfully.
  3. If #185 (overall deadline) has merged, only retry when there is time left.
  4. Keep the retry logic in a small helper with a comment that says why only this call is retried. Future contributors will be tempted to add retries elsewhere, and the comment should stop them.

Tests

  • ConnectError then success: the profile is returned, and two profile_fetch calls are recorded.
  • ConnectError twice: ProfileFetchError (502) is raised, and the client is closed.
  • A 503 then a 200: it succeeds.
  • ReadTimeout, a 404, an error envelope and an unparseable response are not retried.
  • The login POST is called exactly once even when it fails (a regression guard).
  • The live suite passes.

Acceptance criteria

  • One transient failure of the profile call no longer fails a login
  • The login is provably never retried (there's a test)
  • Every attempt appears in upstream_requests_total{operation="profile_fetch"}

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 #186 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.