On this page

For Quality

What to test

Email/password login (Login.js) and clinic-login-name login (LoginWithCompany.js) for accounts in each configured region.
Login with an email/company that doesn't exist — confirm no distinguishable error is leaked that would let an attacker tell a real account from a fake one (the anti-enumeration fake-region logic is deliberate; a leak here would be a regression of that protection, not just a UX bug).
2FA and rate-limiting behavior on top of the new lookup step — confirm neither was broken by inserting the region lookup ahead of them.
Password reset and email verification token lookups, since those go through the same region-resolution machinery as login.

Add a second account in the same region as the active one, and confirm switching uses the lighter-weight same-region SWITCH_USER path (no full page reload) versus a different-region account (which does a full client swap).
Remove a stored account and confirm it's gone from the switcher but the underlying account itself is untouched.
Log out of the active account while a second stored account exists — confirm the fallback-to-next-account behavior is intentional, not a bug, and doesn't leak into a state where the "wrong" account appears active without the user choosing it.
Cross-check the two multi-account storage implementations noted in Region-Aware Login & Multi-Account (regionAccountsStorage.js vs accountStore.ts) don't produce inconsistent state if both are exercised.

A patient-timeline/appointment/lab-order link generated before this PR's routing hint existed — confirm the fallback (brute-force scan across regions) still resolves correctly, just slower.
A link with a stripped or corrupted ?c= hint — confirm it fails open sensibly rather than erroring the page.

Cron Jobs screen: confirm the region dropdown, cron table, Execute buttons, and Redis get/reset tools all stay in sync with the selected region, and that switching regions clears/refetches rather than showing stale data from the previous region.
Cross-region aggregate queries (company/branch/user search and listing, analytics/statement queries) — confirm merged results are actually complete across all regions and not silently missing one region's data, and that sort/pagination behaves sensibly across the merge.
adminDisableTwoFactor and other entity-scoped mutations that now take a company argument to resolve region directly — confirm the fallback (searching all regions when company is omitted) still works.

This is CLI/ops tooling, not app UI, but it's the highest-risk code in the PR (moves real customer data). At minimum: run a dry run against a non-trivial seeded company and verify the estimate numbers are sane; run a real migration end-to-end in a test environment and verify data integrity on the target, that the source is properly disabled (not deleted), and that global routing correctly points at the target afterward; verify the blocker checks actually block (create a pending upload/payment/e-invoice and confirm the migration refuses to proceed); verify resume behavior after a forced interruption at a few different points in the flow.
The existing scripts/smoke-test/tests/36-company-region-migration.test.ts (806 lines) is the closest thing to an existing automated check for this — read it before designing additional manual test cases, to avoid duplicating coverage.

Fake-region responses on unknown lookups are correct-by-design, not a bug — don't file "lookup returns success for an email that doesn't exist" as a defect without checking getFakeRegion in lookup.js first.
Regional servers must never write to the global database directly (globalClient.js's own doc comment says so) — any code path found doing so is a real architectural violation worth flagging seriously, not a style nit.
The internal GraphQL surface (/internal/graphql on each regional server) is guarded by a static bearer token and an operation whitelist, not user auth — confirm it actually rejects unlisted operations, batched requests, and introspection, since this endpoint bypasses the normal auth/permission layer entirely by design.
Local dev override in lookup.js: when NODE_ENV=development and the request Origin contains localhost/127.0.0.1, region resolution is forced to a local backend URL regardless of the real lookup result — make sure this can't leak into any deployed environment's behavior.
This PR "has never been tested" in production per its own planning doc — treat existing manual test notes/runbooks as a starting checklist, not a substitute for actually exercising the two-region local Docker stack (scripts/smoke-test/run.sh) yourself before signing off on anything migration-adjacent.

Generated from the feat/accounting-module PR · internal documentation