Skip to content

01a034d6 - Keep the verification-call section visible after Completed and Failed - #1426

Open
joshuakrueger-dfx wants to merge 6 commits into
DFXswiss:developfrom
joshuakrueger-dfx:fix/verification-call-section-visibility
Open

01a034d6 - Keep the verification-call section visible after Completed and Failed#1426
joshuakrueger-dfx wants to merge 6 commits into
DFXswiss:developfrom
joshuakrueger-dfx:fix/verification-call-section-visibility

Conversation

@joshuakrueger-dfx

@joshuakrueger-dfx joshuakrueger-dfx commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

EN:
The verification-call section on Settings now stays on the page after Completed and Failed, so the mail link /settings?a=call still has a target. Completed shows a short notice; Failed shows a notice and a button that opens a new-call support request. Open statuses keep the existing consent form.

DE:
Die Sektion Verifizierungsanruf bleibt nach Completed und Failed sichtbar, damit der Mail-Link /settings?a=call ein Ziel hat. Completed zeigt einen Hinweis; Failed einen Hinweis und einen Button für eine neue Anruf-Anfrage. Offene Status behalten das bisherige Formular.

Open, and not closable from this branch:

  • Re-evaluate the review. marassteiner requested changes on 8c2d7db8; both blockers are implemented on 1a043d1a, but only the reviewer can resolve the request. reviewDecision is still CHANGES_REQUESTED.
  • Dispose of the failed Ensure CI label run on the superseded head 053c277f — needs admin rights on this repository. It is red by design: the job refuses a fork head (GITHUB_TOKEN cannot workflow_dispatch a fork head) and asks for a human-applied ci label, which also needs admin (403 here). Deleting the run and re-running it both return 403 for this account, and re-triggering ready_for_review would only move the same failure onto the current head. The head itself is clean: 7 of 7 check runs on 1a043d1a are success, because pr.yml triggers on pull_request: synchronize with draft == false and the push of 1a043d1a started them.
  • Regenerate user-flows.spec.ts-settings-main-chromium-darwin.png. It needs the full local stack (the api repository as a sibling checkout plus Docker), which this branch cannot provide. See the note below — it is stale on develop, not stale because of this pull request.

Symptom (verbatim): für die Vereinbarung eines Telefonats hatten Sie mir einen link zugeschickt. Nach dem Öffnen sollte ich mögliche Zeiten auswählen können. Beim Anklicken des links komme ich auf keine Seite, auf der ich einen Termin angeben kann.

Scale: 1041 Completed accounts see nothing at the mail target; 51 Failed accounts are told by mail to act on that page while the section is hidden. The form itself still works: 17 accounts set a call time on 2026-08-24.

Smaller fix considered: Always render the section and replace the two dropdowns with a status notice at Completed and Failed — about 25 lines in one file, no API change. That is this PR.

Review blockers, implemented on 1a043d1a:

  1. Coverage. src/screens/settings.screen.tsx is at 100 % statements, 100 % branches, 100 % functions, 100 % lines (was 40.9 / 46.15 / 26.31 / 41.34). 28 tests in 2 suites, both green.
  2. Handbook. e2e/settings-verification-call.spec.ts gained the Completed and Failed variants with two committed baselines; the three consent variants and the metadata.json key came from 01a04085 - Handbook coverage for the Settings verification-call choice #1434, which merged into develop on 2026-08-27 at 09:33 while this branch was open. This pull request therefore extends that spec instead of adding a second one.

Review point 3 (a should) stays open on purpose: e2e-stack/specs/account.spec.ts already claims /settings and is not extended to assert the notices. No new route is added.

Round check (1a043d1):
Twins: rg 'useAnchor\(' over src/ returns exactly two call sites: this one and account.screen.tsx:115 (useAnchor('recommendation', recommendationsRef, …)). The second one has the same shape — its anchor target at account.screen.tsx:530 renders only inside {isKycLevel50 && …}, so a deep link to /account?a=recommendation from an account below level 50 lands nowhere. Whether any mail sends that link is decided in the api repository, not here, so it is reported and not fixed in this pull request. No other anchor exists; rg '\?a=' over src/ finds no in-app link, only the mail target.
New surface: the rebase onto 76a4fc79, the two Playwright cases in the spec merged with #1434, the reality-declaration paragraph in docs/test-architecture.md, src/__tests__/settings-screen.test.tsx (767 lines) and 37 added lines in src/__tests__/verification-call-section.test.tsx. All of it was read back; the two exports in settings.screen.tsx are the only production change beyond the section itself.
Previous findings: the two blockers of the 2026-08-26 review hold as implemented, evidenced by the numbers below. Two findings of my own review lanes were measured and fixed in 053c277f — removing ref={verificationCallRef} and emptying an effect dependency array both passed all 25 tests before; both fail now. Three lane findings about the pull-request description (stale baseline names, a misquote of CONTRIBUTING, numbers from the pre-rebase head) are fixed by this rewritten description. Four suspicions raised by the lanes were withdrawn after being checked against the code: button colour, a Prettier gate for TypeScript, a lint rule against nested ternaries, and Markdown re-wrapping — none of those gates exist in this repository.

Final pass (1a043d1):
Coherent: every file serves the one title — the section itself, three translations, the tests that pin it, and the two handbook variants that show it. Two empty commits, 153265e5 and 1a043d1a, carry no diff at all; they exist because the heavy jobs only run on a push made while the pull request is not a draft. They are kept rather than rebased away, because another rebase is another chance to lose a fix silently.
Nothing extra: no API change, no new route, no new spec file, no second metadata.json key, and the open/consent baseline was not rebuilt because #1434 already committed it. The one production change beyond the section is export on OverlayType and SettingsOverlay; the reason is spelled out below, and it is a deviation from what CONTRIBUTING literally asks for.
Sources closed: the customer mail (symptom quoted above); the hide condition in settings.screen.tsx; the review of 2026-08-26 — blocker 1 and 2 implemented, point 3 declined with a reason; PR #1434 as the source of the spec this change extends; and three independent review lanes whose findings are listed under Previous findings.

Skipped check (K1.13): Three workflows have no check on this head, each for a reason outside the diff: Ensure CI label only fires on ready_for_review and the head was pushed after that, codeql.yml declares its job as Analyze (${{ matrix.language }}) and actually reported as Analyze (actions) and Analyze (javascript-typescript), both green, and Main only from develop applies to pull requests targeting main, while this one targets develop.

CI on 1a043d1a: 7 of 7 green — Build and test (5m57s), Analyze (actions), Analyze (javascript-typescript), CodeQL, review, Build handbook image + container smoke, Full-stack E2E. One caveat on the last one: it finished in 5 s, which is the known no-op path — without the api checkout credential the job reports success without starting the stack. Its green tick is therefore not evidence.

Details

The mail to /settings?a=call never expires. After Compliance sets phoneCallStatus to Completed or Failed, the settings screen used to drop the whole section, including the heading the anchor scrolls to. The page loaded, the customer saw nothing at that spot.

This change renders the section whenever isUserLoading is false. Completed shows only the notice. Failed shows the notice and a button to /support/issue?issue-type=VerificationCall&reason=RepeatCall. Every other status, including unset, keeps the existing consent dropdowns. Effects and updateCallSettings are unchanged. No API change.

Coverage of src/screens/settings.screen.tsx

Metric Before Now
Statements 40.9 % 100 %
Branches 46.15 % 100 %
Functions 26.31 % 100 %
Lines 41.34 % 100 %

Measured with --collectCoverageFrom='src/screens/settings.screen.tsx' over both suites: Test Suites: 2 passed, 2 total / Tests: 28 passed, 28 total.

src/__tests__/settings-screen.test.tsx (new, 767 lines) covers what the verification-call suite does not: the four form effects in both directions, the bank-account list including loading, absent accounts, the label and DEFAULT fallbacks and every menu action, the address list including the custody filter, the ACTIVE tag and all four menu actions, the layout title and its onBack, the Danger Zone, and all seven SettingsOverlay cases with their onConfirm, onCancel, onEdit and onSubmit callbacks.

The one production change beyond the section, and why it deviates from CONTRIBUTING: OverlayType and SettingsOverlay are now exported. The default branch of the overlay switch cannot be reached through SettingsScreen, which renders the overlay only for a truthy overlayType, so OverlayType.NONE never arrives there. CONTRIBUTING says to delete a line that genuinely cannot be exercised rather than exclude it from the measurement. Deleting this one is possible only by narrowing the prop type to Exclude<OverlayType, OverlayType.NONE> and casting at the call site, because the switch has to stay exhaustive for the compiler — that is more production code touched than two export keywords. The export is the smaller change, and it is a conscious deviation, not an oversight. Say the word and it becomes the narrowed prop type instead.

Counter-probes. Removing the fix itself (git apply -R of the production hunk of d3ef0612) fails 6 of 28 Jest tests and 2 of 5 Playwright cases. Beyond that, each probe below flips one condition and leaves the code runnable, because a deletion probe only proves a fragment is present:

Mutation Result
ref={verificationCallRef} removed from the heading 2 of 28 fail
}, [selectedLanguage]);}, []); 1 of 22 fail
}, [selectedPreferredPhoneTimes]);}, []); 1 of 28 fail
}, [acceptCall]);}, []); 1 of 22 fail
filter((a) => !a.isCustody)filter((a) => a.isCustody) 1 of 22 fail
account.default ? 'Default' : undefined!account.default ? … 1 of 22 fail
userAddress.address === user?.activeAddress?.address && setWallet()!== 2 of 22 fail

The first two rows are the reason for commit 053c277f: before it, both of those mutations passed all 25 tests. Removing the ref is half of the reported bug — the mail link scrolls to that heading — and an emptied dependency array made every effect mount-only in the test, because the suite mocks react-hook-form with a static useWatch. My own review lanes found both; I measured them before accepting them, then closed them with two tests and re-measured.

The probes from the earlier round still hold for the verification-call suite: restoring the old Completed/Failed hide condition fails 2 of its original 4 tests, swapping the Completed and Failed branches fails 2 of 4.

Handbook

e2e/settings-verification-call.spec.ts was merged into develop with #1434 on 2026-08-27 (e73764f6), covering the three consent states. This pull request adds the two variants it is actually about:

  • settings-verification-call.spec.ts-settings-verification-call-04-completed-chromium-darwin.png
  • settings-verification-call.spec.ts-settings-verification-call-05-failed-chromium-darwin.png

Written once with --update-snapshots (2 written), then the whole spec re-run without it: 5 passed, so the three baselines from #1434 reproduce here too. scripts/handbook/metadata.json keeps its existing key and title; only the description grows to name all five variants. docs/test-architecture.md is corrected in the same commit: its reality declaration said a green run does not prove that "Completed/Failed hide the section" — after this change they no longer hide it.

A local handbook build (node scripts/handbook/build.js docs/handbook/build) reports wrote 228 screenshots, 9 docs, 4 assets and carries both new files in manifest.json. The one stderr warning it prints, an orphaned compliance-bank-tx-return entry, predates this branch.

The spec answers every request itself and passes nothing through to a real backend; REACT_APP_API_URL pointed at a dead port during the run. Unmatched /v1/** and /v2/** calls are fulfilled with 501. Note that the spec does not assert the set of unexpected requests — it has no such collector, and this change does not add one.

settings-main.png is stale, and this pull request does not fix it. e2e/screenshots/baseline/user-flows.spec.ts-settings-main-chromium-darwin.png was last written on 2026-01-06 (#844). It shows neither the verification-call section nor the "Danger Zone" heading, both of which exist on develop today — so it was already stale before this branch, and regenerating it would pull two unrelated drifts into this diff. It also needs the full local stack. The five mocked variants of the same screen cover the change itself.

Gates run locally (Node 20, the version pr.yml pins), all on 053c277f:

Command Result
npm run lint exit 0, empty output
npm run format:md:check exit 0, all files formatted
npm test (full) Test Suites: 1 failed, 113 passed, 114 total / Tests: 1 failed, 1770 passed, 1771 total
npm run build:dev exit 0
npm run widget:dev exit 0
npx playwright test e2e/settings-verification-call.spec.ts 5 passed

The failing suite is realunit.screen.test.tsx, which expects 1,000 where the machine renders 1.000. Control run of that same file on the unmodified commit 44ba2432: Test Suites: 1 failed, 1 total / Tests: 1 failed, 21 passed, 22 total; git log 44ba2432..origin/develop -- src/__tests__/realunit.screen.test.tsx src/screens/realunit.screen.tsx is empty, so the control still applies to this base. It is a locale difference, not a regression from this branch.

What is not verified here

  • Full-stack E2E is green in 5 s, which is the no-op path: without the api checkout credential the job reports success without starting the stack. It proves nothing about this change.
  • The pull request now carries two empty commits, 153265e5 and 1a043d1a. Both exist only to start CI after leaving draft; removing them means another rebase, and a rebase is another chance to lose a fix silently.
  • The Playwright visual tests do not run in CI by design (CONTRIBUTING, "Visual regression tests"), so the baselines are a review aid, not a gate.
  • Full-stack E2E reports success on pull requests without starting the stack when the api checkout credential is absent; a green tick there is not evidence.
  • The scale numbers come from a production query on 2026-08-24 and were not re-measured for this head.
  • Whether a mail links to /account?a=recommendation is decided in the api repository; the twin anchor described above is reported, not fixed.

@joshuakrueger-dfx

Copy link
Copy Markdown
Contributor Author

EN:
Grok and Codex logic lanes report zero defects; conformity still wants 100% coverage of the whole settings screen and Completed/Failed screenshot baselines, which this PR declares and does not implement.

DE:
Grok- und Codex-Logik melden null Mängel; die Konformität verlangt weiter 100% Coverage der ganzen Settings-Datei und Baselines für Completed/Failed, die dieser PR deklariert und nicht baut.

Details

Head 3dd7f3e3, verified. Local Node 20: lint empty; new suite 4/4; deletion probe 2 of 4 fail; mutation (swapped Completed/Failed) 2 of 4 fail. Full suite 1479/1480 — the one failure is realunit.screen.test.tsx (1,000 vs 1.000) on unmodified develop too.

Grok A: coverage of settings.screen.tsx and missing visual variants. Grok B: 0. Codex A: same two, and refuses the declared CONTRIBUTING deviation (declaration is not a grant). Codex B: 0.

CI on this draft is skipped (draft == true and no ci label). This account cannot add labels on DFXswiss/services.

The PR stays draft until a reviewer grants the two deviations or the extra tests and baselines are added, and until CI has actually run.

@joshuakrueger-dfx

Copy link
Copy Markdown
Contributor Author

EN:
User-Entscheid: keep the declared CONTRIBUTING deviations; do not expand this PR to 100% settings-screen coverage or Completed/Failed screenshot baselines.

DE:
User-Entscheid: die deklarierten CONTRIBUTING-Abweichungen bleiben; dieser PR bekommt keine 100%-Coverage der Settings-Datei und keine Completed/Failed-Baselines.

User-Entscheid: keep the declared CONTRIBUTING deviations for coverage of the whole settings screen and for Completed/Failed Playwright baselines. The mail-link dead end is fixed by the section change; overlay, bank and address paths are untouched.

@joshuakrueger-dfx
joshuakrueger-dfx marked this pull request as ready for review August 24, 2026 19:35
@joshuakrueger-dfx
joshuakrueger-dfx marked this pull request as draft August 24, 2026 19:37
@joshuakrueger-dfx
joshuakrueger-dfx marked this pull request as ready for review August 24, 2026 19:53
@joshuakrueger-dfx

Copy link
Copy Markdown
Contributor Author

@marassteiner please review — head 8c2d7db8.

EN:
This is a PR, not an issue: 5 files against develop, head 8c2d7db8, 6/6 checks green.

DE:
Das ist ein Pull Request, kein Issue: 5 Dateien gegen develop, Head 8c2d7db8, 6 von 6 Checks grün.

@marassteiner

Copy link
Copy Markdown
Collaborator

EN: Working on this now — job dfxswiss__app__1426__pr-review.
DE: Ich arbeite jetzt daran — Auftrag dfxswiss__app__1426__pr-review.

@marassteiner marassteiner left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EN:
Changes requested: whole-file coverage of settings.screen.tsx and Completed/Failed handbook baselines are still missing, and the author's declared deviations are not a reviewer grant.

DE:
Änderungen nötig: die 100%-Coverage der ganzen Settings-Datei und die Handbook-Baselines für Completed/Failed fehlen weiter; die deklarierten Abweichungen des Autors sind keine Reviewer-Freigabe.

Details

Head 8c2d7db8b6d23fda985667388723c48ce95cb606 against develop. Logic of the verification-call section is sound. Conformity is not.

Blocking

  1. src/screens/settings.screen.tsx (changed branch around lines 300–368). CONTRIBUTING requires 100% statement, branch, function and line coverage for every touched Jest-instrumented file. This file is in collectCoverageFrom. The new tests in src/__tests__/verification-call-section.test.tsx cover only the verification-call states. Overlay, bank-account and address paths in the same file are untouched. A declared deviation is not a granted one; the author cannot grant their own deviation.

    Fix: bring the whole file to 100% on all four metrics and state the numbers in the pull-request description, or obtain a written grant from a reviewer on this pull request.

  2. src/screens/settings.screen.tsx:309–329. The change introduces Completed-notice and Failed-notice+button visual variants. CONTRIBUTING handbook coverage must be complete: each visual variant needs a committed Playwright baseline and an entry in scripts/handbook/metadata.json. e2e/user-flows.spec.ts already has settings-main.png; that baseline does not cover Completed or Failed. This diff adds neither baselines nor metadata.

    Fix: add toHaveScreenshot for at least the open/consent, Completed and Failed variants, commit the baselines, update scripts/handbook/metadata.json — or obtain a written grant from a reviewer.

Noted, not blocking

  1. CONTRIBUTING says a screen change should bring or update the matching full-stack test. /settings is already claimed by e2e-stack/specs/account.spec.ts, which does not assert the Completed/Failed notices. No new route. This is a should, not the coverage/handbook must.

The User-Entscheid comment on this pull request is from the author. It records product intent; it does not grant the deviations.

Do not merge until the blockers are fixed or a reviewer grants the declared deviations in writing.

@joshuakrueger-dfx
joshuakrueger-dfx marked this pull request as draft August 27, 2026 09:23
@joshuakrueger-dfx

Copy link
Copy Markdown
Contributor Author

@marassteiner both blocking points are implemented on head 3a54651e, not declared.

EN:
settings.screen.tsx is at 100 % on all four metrics (was 40.9 / 46.15 / 26.31 / 41.34), and the three visual variants have committed baselines plus a metadata.json entry. Point 3, the full-stack spec, is still open — it is a should and I left it out on purpose.

DE:
settings.screen.tsx steht auf 100 % in allen vier Metriken (vorher 40.9 / 46.15 / 26.31 / 41.34), die drei visuellen Varianten haben committete Baselines und einen metadata.json-Eintrag. Punkt 3, der Full-Stack-Spec, bleibt bewusst offen — er ist ein should.

Details

1. Coverage. src/__tests__/settings-screen.test.tsx (new, 723 lines) covers the paths the verification-call suite left out: the four form effects in both directions, the bank-account list (loading, absent, label and DEFAULT fallbacks, all four menu actions), the address list (custody filter, ACTIVE tag, all four menu actions), the layout title and its onBack, the Danger Zone, and all seven SettingsOverlay cases with their callbacks.

File                 | % Stmts | % Branch | % Funcs | % Lines
 settings.screen.tsx |     100 |      100 |     100 |     100
Test Suites: 2 passed, 2 total
Tests:       25 passed, 25 total

One production change comes with it: OverlayType and SettingsOverlay are exported. The default branch of the overlay switch is unreachable through SettingsScreen, which renders the overlay only for a truthy overlayType, so OverlayType.NONE never arrives there. CONTRIBUTING asks to make such a line reachable rather than exclude it, and the export is the smallest way to do that. Say the word if you would rather see the branch removed with a narrowed prop type instead.

Because a coverage number alone says nothing about what the tests assert, three mutation probes, each flipping one condition and leaving the code runnable:

Mutation Result
filter((a) => !a.isCustody)filter((a) => a.isCustody) 1 of 25 tests fails
account.default ? 'Default' : undefined!account.default ? … 1 of 25 tests fails
userAddress.address === user?.activeAddress?.address && setWallet()!== 2 of 25 tests fail

2. Handbook. e2e/settings-verification-call.spec.ts (new, 224 lines) opens /settings?session=<token> with a synthetic alg: 'none' token and mocks the api completely — GET /v2/user, /v1/language, /v1/fiat, /v1/bankAccount, /v1/asset, /v1/country, /v1/setting/infoBanner. Nothing reaches a real backend: REACT_APP_API_URL pointed at a dead port during the run, and any request outside that list is answered 501 and asserted empty at the end of each test. The local seed carries no account with a Completed or Failed phone-call status, so those variants are not reachable otherwise. All data in the images is synthetic.

Three baselines committed under e2e/screenshots/baseline/: …-open-…png, …-completed-…png, …-failed-…png, plus the settings-verification-call entry in scripts/handbook/metadata.json. Written once with --update-snapshots, then re-run without it: 3 passed. A local handbook build reports wrote 226 screenshots, 9 docs, 4 assets and carries all three in manifest.json.

3. Full-stack spec — not done. /settings stays claimed by e2e-stack/specs/account.spec.ts and is not extended to assert the notices. No new route.

Gates, Node 20: npm run lint exit 0 with empty output, npm run format:md:check exit 0, npm run build:dev and npm run widget:dev exit 0, full Jest Test Suites: 1 failed, 110 passed, 111 total / Tests: 1 failed, 1500 passed, 1501 total. The failing suite is realunit.screen.test.tsx (1,000 vs 1.000); a control run of that same file on the unmodified base commit 44ba2432 fails identically — a locale difference, not a regression.

Open, and not closable from this branch: the pull request is a draft, and ci-on-ready.yaml dispatches the heavy jobs only on ready_for_review, so no check has run on 3a54651e. This account cannot set the ci label here. The final-pass and Mara lines in the description belong to 8c2d7db8 and have not been repeated for this head.

…ailed

The mail link to /settings?a=call found no target once phoneCallStatus was
Completed or Failed. The heading now always renders, with a status notice
and — for Failed — a button to request a new call.
CONTRIBUTING requires 100% statement, branch, function and line coverage for every touched file. The verification-call tests covered only their own states, so the bank-account, address, form-effect and overlay paths of the same file stayed uncovered.

OverlayType and SettingsOverlay are exported because the NONE branch of the overlay switch cannot be reached through the screen, which only renders the overlay for a truthy type.
The spec merged with DFXswiss#1434 covers the three consent states. Completed and Failed are the two variants this pull request introduces, so they were still missing from the handbook.

The reality declaration said a green run does not prove that Completed/Failed hide the section; after this change they no longer hide it, so the sentence is replaced by the limits the new images actually have.
@joshuakrueger-dfx
joshuakrueger-dfx force-pushed the fix/verification-call-section-visibility branch from 3a54651 to fe57920 Compare August 27, 2026 10:41
Two mutations passed every test before this commit: removing ref={verificationCallRef} from the heading, and emptying any of the four effect dependency arrays. The first is half of the reported bug — the mail link /settings?a=call scrolls to that heading — and the second made the effects mount-only in the test.
@joshuakrueger-dfx

Copy link
Copy Markdown
Contributor Author

@marassteiner update on head 053c277f — and a correction of my previous comment.

EN:
Both blockers are implemented. Since my last comment the branch was rebased onto develop, which brought in #1434 — your handbook spec for the same section. This pull request now extends that spec with the two variants it is about instead of adding a competing one.

DE:
Beide Blocker sind umgesetzt. Seit meinem letzten Kommentar wurde der Branch auf develop rebased; dabei kam #1434 dazu — dein Handbook-Spec für dieselbe Sektion. Dieser PR erweitert ihn jetzt um die zwei Varianten, um die es hier geht, statt einen konkurrierenden anzulegen.

Correcting my previous comment. It described the pre-rebase head 3a54651e and was wrong in three places: it named three baseline files that do not exist on this branch (the open/consent one is yours, from #1434), it called e2e/settings-verification-call.spec.ts new when it already existed on develop, and it quoted CONTRIBUTING as asking to "make the line reachable" — it says delete it. The pull-request description is rewritten against this head.

Details

1. Coveragesrc/screens/settings.screen.tsx at 100 % on all four metrics (was 40.9 / 46.15 / 26.31 / 41.34), Test Suites: 2 passed / Tests: 28 passed, 28 total.

Removing the fix itself fails 6 of 28 Jest tests and 2 of 5 Playwright cases. Seven mutation probes, each flipping one condition and leaving the code runnable:

Mutation Result
ref={verificationCallRef} removed from the heading 2 of 28 fail
}, [selectedLanguage]);}, []); 1 of 22 fail
}, [selectedPreferredPhoneTimes]);}, []); 1 of 28 fail
}, [acceptCall]);}, []); 1 of 22 fail
filter((a) => !a.isCustody)filter((a) => a.isCustody) 1 of 22 fail
account.default ? 'Default' : undefined!account.default ? … 1 of 22 fail
userAddress.address === user?.activeAddress?.address && setWallet()!== 2 of 22 fail

The first two rows are worth naming: before commit 053c277f both of them passed all 25 tests. Removing the ref is half of the reported bug — the mail link /settings?a=call scrolls to that heading — and an emptied dependency array made every effect mount-only, because the suite mocks react-hook-form with a static useWatch. My own review lanes found both, I measured them before accepting them, and 053c277f closes them with two tests.

2. Handbook — two baselines added to your spec, …-04-completed-…png and …-05-failed-…png, written once with --update-snapshots and then the whole spec re-run without it: 5 passed, so your three baselines reproduce here too. metadata.json keeps your key and title; only the description grows to name all five variants. docs/test-architecture.md needed a correction in the same commit: its reality declaration said a green run does not prove that "Completed/Failed hide the section" — after this change they no longer hide it.

A local handbook build reports wrote 228 screenshots, 9 docs, 4 assets with both files in manifest.json.

One deviation, stated plainly. OverlayType and SettingsOverlay are exported so the default branch of the overlay switch is reachable — through SettingsScreen it is not, because the overlay renders only for a truthy overlayType. CONTRIBUTING asks to delete an unreachable line. Deleting this one means narrowing the prop type to Exclude<OverlayType, OverlayType.NONE> and casting at the call site, since the switch has to stay exhaustive for the compiler — more production code touched than two export keywords. Tell me which you prefer and I will change it.

Point 3 stays open on purpose: e2e-stack/specs/account.spec.ts already claims /settings and is not extended. It is a should, and no new route is added.

A twin, reported not fixed: account.screen.tsx:115 uses the same anchor pattern (useAnchor('recommendation', …)), and its target at :530 renders only inside {isKycLevel50 && …}. A deep link to /account?a=recommendation below level 50 lands nowhere — the same failure mode. Whether a mail sends that link is decided in the api repository, so it is out of scope here.

Gates on 053c277f, Node 20: npm run lint exit 0 with empty output, npm run format:md:check exit 0, npm run build:dev and npm run widget:dev exit 0, full Jest Test Suites: 1 failed, 113 passed, 114 total / Tests: 1 failed, 1770 passed, 1771 total. The failing suite is realunit.screen.test.tsx (1,000 vs 1.000); a control run of that file on the unmodified commit 44ba2432 fails identically and the file has not changed since — a locale difference, not a regression.

Open and not closable from this branch: no CI check has run on 053c277f — all five report skipping while the pull request is a draft, and this account cannot set the ci label. user-flows.spec.ts-settings-main-chromium-darwin.png is stale since 2026-01-06 (it shows neither this section nor the Danger Zone heading); regenerating it needs the full local stack and would pull two unrelated drifts into this diff.

@joshuakrueger-dfx
joshuakrueger-dfx marked this pull request as ready for review August 27, 2026 11:14
The heavy jobs run on pull_request: synchronize with draft == false. This branch was last pushed while the pull request was still a draft, so they were skipped; Ensure CI label cannot dispatch them because the head lives in a fork.
@joshuakrueger-dfx

Copy link
Copy Markdown
Contributor Author

CI is green on 1a043d1a: 7 of 7 checks pass — Build and test (5m57s), Analyze (actions), Analyze (javascript-typescript), CodeQL, review, Build handbook image + container smoke, Full-stack E2E.

EN:
The earlier red Ensure CI label was not caused by this diff. That job cannot workflow_dispatch a fork head, and applying the ci label needs admin rights. The heavy jobs never needed it: pr.yml runs on pull_request: synchronize with draft == false, so a single push after the pull request left draft started all of them. That push is the empty commit 1a043d1a.

DE:
Der rote Ensure CI label kam nicht aus diesem Diff. Der Job kann keinen Fork-Head dispatchen, und das ci-Label zu setzen braucht Admin-Rechte. Die schweren Jobs brauchen beides nicht: pr.yml läuft auf pull_request: synchronize mit draft == false — ein Push nach dem Verlassen des Draft-Status startet sie. Dieser Push ist der leere Commit 1a043d1a.

Two things a green tick does not cover here: Full-stack E2E finished in 5 s, which is the no-op path without the api checkout credential, and three workflows have no check on this head — Ensure CI label (fires only on ready_for_review), codeql.yml (declared as Analyze (${{ matrix.language }}), reported as the two green Analyze (…) runs) and Main only from develop (applies to pull requests targeting main). Both are stated in the description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants