ElanoryaAccounts
Submitting the registration form hands you to verification, not into a session
Registration and signing in are two different events in this app. The registration call creates the account and sends you to the verification step; the session is established when the code is accepted. Closing the app in between is no longer a dead end, because the address you registered with is remembered on the device.
What the registration call does, and what it leaves undone
Two events that usually arrive together are separate here. Keeping them apart explains everything the screen does next.
- The call creates the account.
- That part completes on submission. There is nothing left to resubmit, and resubmitting the form does not advance the remaining step.
- The call does not establish a session.
- The session comes later, when the code is accepted. Verified in apps/jewelry-mobile/src/features/auth/auth-provider.tsx, at the registration call await apiRegister(email, password).
- The handoff is deliberate, and it is tested.
- The registration screen's test expects the move to '/(auth)/verify' after a successful submission, in apps/jewelry-mobile/src/features/auth/register-screen.test.tsx. A screen that lands you there is behaving as specified.
- A social sign-in, where a build offers one, does not follow this shape.
- That route settles identity in one step rather than in two. Whether any given build offers it is not something this page states.
- Going back instead of verifying does not lock you out.
- A user who leaves the verification step can still enter the app, in the unverified state. What that state permits is a separate subject and is not opened here.
The verification screen and the address it already holds
The verification screen is written to work with or without knowing who it is verifying. When the address is known it asks only for the code, because asking again for something it holds would be a pointless keystroke. When it is not known it shows an email field first, which is what makes the screen usable by someone who arrives at it directly rather than straight from the form.
Both faces are the same screen, and which one you get is decided by whether an address is on hand. That is why two sellers can describe the step differently and both be right.
The address is kept on the device between the two steps. The comment beside that storage records what it replaced: previously a user who could not complete verification in one sitting had a single way forward, which was to register from the beginning. Verified in apps/jewelry-mobile/src/features/auth/pending-email-storage.ts. Closing the app, taking a call, or putting the phone down mid-registration therefore costs the code entry, not the registration.
The stored address does not outlive the account on that device: it is cleared on sign-out and when the account is removed. A phone handed to someone else does not present the previous owner's address at this step.
Each way you reach the verification step, and what remains
Every row below is the same screen. What differs is what it already knows when you get there.
| How you arrived | What the screen shows | What still has to happen |
|---|---|---|
| Straight from the registration form | The code entry, with the registered address already known | Enter the code; the session is established when it is accepted |
| You closed the app between registering and verifying | The same code entry, with the address restored from the device | Enter the code; registering again is not required and does not help |
| You reached the screen without the app holding an address | An email field ahead of the code entry | Supply the address, then the code |
| You went back instead of verifying | The app itself, with the account in the unverified state | Verification remains outstanding; that state is described on its own page |
Where the handoff is misread, and what it costs
Each of these is a reasonable guess about a form that did not end in a session, and each has a concrete cost.
Submitting the registration form again after landing on the verification screen.
The account was created by the first submission. Continue on the verification screen; a second registration produces a second address rather than a session.
Starting over because the app was closed part-way through.
The address is restored from the device when the screen reopens. Only the code entry is outstanding.
Reading the email field as evidence that the earlier step was lost.
The field appears only when the screen does not already hold an address, which is a statement about how you arrived, not about what happened before.
Waiting for a welcome notice before believing the account is live.
The notice belongs to a fresh registration or first sign-in and is shown once; it is withheld entirely when the server reports the account already existed.
Leaving a session in place on a shared studio phone so the next person can 'carry on'.
The stored address is cleared on sign-out and on account removal, and the next person should be registering or signing in as themselves.
Limits of what this page establishes
The evidence here is the mobile client's registration and verification behaviour. The following sit outside it.
- What an account can and cannot do while its address is unverified, and how the resend control behaves. Both belong to the unverified state and are described on their own page.
- The routing rule that decides which screens open before you have a session at all. That is a separate subject and is not restated here.
- Any verification parameter: code length, how long a code remains usable, how many attempts are allowed. These are server-side and are not readable from the client.
- Any amount, package name, price or currency the welcome notice may show. This page names the notice and its two tones, and nothing it reports.
- Whether a build offers a social sign-in route at all. The one-step shape is stated conditionally because the client code does not reveal which providers a shipped build carries.
- What account removal does on the server. The only removal effect stated here is local: the stored address is cleared from the device.
Questions
I completed the registration form but the app did not sign me in. Did it fail?
No. The registration call creates the account and returns without establishing a session, and the registration screen then sends you to the verification step. The session is established when the code is accepted, so the missing sign-in is the design of the step rather than an error.
The app closed between registering and entering the code. Do I have to register again?
No. The address you registered with is stored on the device and restored by the verification screen, so only the code entry is outstanding. Registering again was the only way out of this situation before the address was made to persist.
Why is the verification screen asking for my email address?
The email field is shown only when the screen does not already hold an address, which is what allows someone who reaches it directly to finish verifying. When the address is known the field is not shown at all.
I never saw a welcome message after verifying. Did I miss something?
The welcome notice is tied to a fresh registration or first sign-in and is shown once, in one of two tones. A returning user does not see it, and it does not appear at all when the server reports that the account already existed.