Verify page retries every 503, not only central-manager's own
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- backend-api-design, frontend
Direzione di ricerca
Read DESIGN.md, especially “A write with no verdict never reads as failed,” and inspect useVerifyEmailMutation and the page’s Try again flow. Decide whether to keep retrying every 503 or have central-manager mark its retryable response, such as with a Retry-After header, and retry only then. Done means the chosen behavior is implemented and accounts for both central-manager and gateway or Harper 503 responses.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
With the #1697 verification-outcome change, useVerifyEmailMutation retries a 503 from PUT /VerifyEmail/ three times (2s, 4s, 8s) before the page offers Try again. The retry is there for central-manager's own 503, whose message says to retry with the same link, usually because the account's record lock is busy after a node restart.
Studio gates on status, never on the body (DESIGN.md, "A write with no verdict never reads as failed"), so a 503 from a gateway, or from Harper when a worker exits, gets the same 14 seconds of retries. Repeating the PUT is safe either way: a verify that landed answers already_verified, which the page explains. The cost is only a slower failure when the 503 isn't central-manager's.
To decide: keep it, or have central-manager mark its own retryable answer (for example a Retry-After header) and retry only on that.
Review-Deferral: 10faec7ad8362e92 severity=nit category=reliability
🤖 Generated by Claude Code (Claude Opus 5.5); posted via @dawsontoth.
- Lingua principale
- TypeScript
- Stelle
- 5
- Fork
- 4
- Merge medio
- 1g 19h
- PR unite (30g)
- 144
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di HarperFast/studio
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
HarperFast/studio#2070 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
HarperFast/studio#2067 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
HarperFast/studio#2053 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
HarperFast/studio#2026 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
HarperFast/studio#2021 ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di HarperFast/studio
Issue simili
-
Add: Tom Sings TV HDApertaapproved check:passed streams:add
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
duolicious/duolicious#1943 ·
I maintainer di solito rispondono entro 1 giorno
-
bug needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
nightly-labs/openbot#6451 ·
I maintainer di solito rispondono entro 1 giorno
-
Testing Configuration UpdateApertalevel1 nsoc26
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
GauravKarakoti/SecureFlow#1719 ·
I maintainer di solito rispondono entro 1 giorno
-
complexity: easy good first issue impact: low
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
ueberdosis/hocuspocus#1211 ·
I maintainer di solito rispondono entro 1 giorno