Verify page re-sends a token that returns after another instead of keeping its first answer
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
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- frontend
Direzione di ricerca
Read the verify-email page flow introduced by #1697 and trace how token arrivals trigger PUT /VerifyEmail/ and display the response. The issue asks the project to choose between re-sending the request and retaining answers per token, including whether reloads should preserve them. Done means the behavior is decided and the chosen response is shown consistently.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
With the #1697 verify-email change, the page sends PUT /VerifyEmail/ once per arrival of a token. A token that comes back after another one (A, then B, then A again on the same mounted page) is sent again. central-manager then answers already_verified, which the page explains ("If we emailed you a link to set your password, use it before signing in…"), but the first answer, for example that the sign-up password was replaced and a link sent to the address, isn't shown again.
The alternative is to keep each token's answer for the life of the page and show it again without a second PUT. That avoids the repeat request and keeps the definite notice, at the cost of more state. The same question applies to a reload, where only storage would keep the first answer.
To decide: keep the re-send, or keep per-token answers.
Review-Deferral: ef8b2b248908c683 severity=nit category=correctness
🤖 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
-
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
-
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
-
e2e-failure ready-to-code
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
redhat-developer/rhdh-plugin-export-overlays#4733 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
S-Needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 2 giorni