feat(confirm): dedicated end state for confirmed_no_registration#23
Merged
Conversation
The confirm API can report that the share register accepted the email but no wallet registration matched it. That is a permanent outcome; rendering it as the retryable 'unavailable' state sent users into a retry dead-end. New 'no-registration' state with its own copy (check the app email or contact support, no retry CTA), mapped from the 2xx body status, plus visual-matrix views and unit coverage.
Cover the mock loop and the real fetch-to-render seam: a 2xx body with status confirmed_no_registration must surface the no-registration state.
Contributor
Author
|
Quality gate: 2 review passes (conformance + correctness). Pass 1 findings — the mock-state loop and a missing fetch-to-render integration test for the new status — were fixed; pass 2 came back clean. Full suite ran green inside the pinned container (56 passed, 22 baselines, visual matrix check OK). |
TaprootFreak
added a commit
to RealUnitCH/app
that referenced
this pull request
Jul 15, 2026
#862) ## Why RealUnitCH/web#23 adds a dedicated confirm-page end state (`no-registration`) with four new Playwright baselines (18 → 22 PNGs). The handbook deploy stages those baselines behind the `EXPECTED_WEB_BASELINE_COUNT` guard, which requires the count bump and the matching gallery cards in the same change. ## Changes - `handbook.yaml`: `EXPECTED_WEB_BASELINE_COUNT` 18 → 22. - `docs/handbook/de/index.html` (`#spec-web`): four cards for the new views (desktop de/en, tablet, mobile), mirroring the confirm-invalid card group. ## Coupling Merge together with RealUnitCH/web#23 — the guard fails the next handbook deploy if either side lands alone. The PR-level `Handbook Build Check` does not stage web baselines, so this PR's CI is unaffected either way.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The confirm API can respond 2xx with
status: 'confirmed_no_registration'(introduced in DFXswiss/api#4215): the share register accepted the email, but no wallet registration matched it. The page currently renders any unrecognized 2xx status as the retryable 'unavailable' state — a permanent condition presented as a retry loop.Changes
confirm-core.js:mapResultmapsconfirmed_no_registration→ new UI stateno-registration; i18n copy (de authored, en mirrored) advising to check the email used in the app or contact support. No retry CTA — the outcome is permanent.confirm.js/index.html: newstate-no-registrationsection mirroring the 'invalid' section (no CTA), wired into the page-state list and the local-preview?mock=hook.confirm-no-registration(de, all three projects) andconfirm-no-registration-en(desktop) views mirroring the invalid views, with baselines generated inside the pinned Playwright container (18 → 22 PNGs; existing baselines byte-identical).mapResultmapping; the generic i18n-parity and page-key checks cover the new keys.Coupling
The handbook pipeline in RealUnitCH/app guards the staged web-baseline count (
EXPECTED_WEB_BASELINE_COUNT). A companion PR bumps it to 22 with the matching gallery cards — merge that one together with this PR.