Elanorya

Accounts

An unverified address stops spending, not browsing

You can be inside the app with an address that has not been verified yet. Moving around is not what verification controls: a spending attempt is refused on the server, and the screen answers with a warning band and a way to have the code sent again. That control locks itself once a send has happened.

Being unverified is not the same as being signed out

The app tracks an unverified account as its own session state rather than folding it into the signed-out case. The resolution is a single expression in apps/jewelry-mobile/src/features/auth/auth-provider.tsx, which reads emailVerified ? 'authenticated' : 'unverified'. That is why an unverified account gets the app and its own warning band instead of the welcome screen.

It is worth being exact about what that state controls, because it is easy to overstate. It decides which interface is drawn. It does not decide what you are allowed to do: every protected request is still put to the server, and the answer comes back from there.

So the band is not a lock the app is holding. It is the visible half of a decision made elsewhere, shown at the moment the app is told about it. The band itself is drawn by the screen container that wraps the app's screens, which is why it appears above whatever you happen to be looking at.

The resend control, and what it used to get wrong

This control has a recorded history, and knowing it explains behaviour that otherwise looks arbitrary.

It once reported a send that had not happened.
The interface said the code had been sent while the request was being skipped silently. The correction is recorded in the comment in apps/jewelry-mobile/src/features/auth/use-resend-cooldown.ts.
It now locks after a send and shows a countdown.
The lock is the honest form of what the old message was hiding: the state of the control matches whether another send is possible.
The lock survives leaving the screen.
Navigating away and returning does not present an unlocked control, so a fresh-looking screen is not a fresh allowance.
The lock survives closing the app.
Restarting is not a way to clear the countdown, which is worth knowing before trying it on a device that is slow to reopen.
The countdown is held against the address.
It is stored per email address. Verifying a different address starts a separate counter rather than continuing the previous one.
The duration is not stated here.
The value is a parameter of the running system, and this page does not publish it. Read the countdown on screen.

Where the warning band gets misread

Each of these follows naturally from being able to move around the app, and each leads somewhere unhelpful.

  • Reading free navigation as proof that the address is verified.

    Navigation is not what the verification state governs. The band on screen is the statement about your address; the absence of an obstacle is not.

  • Attributing a refusal to the screen or tool you were using at the time.

    The refusal is issued by the server against the account state. The tool in front of you is where it surfaced, not what caused it.

  • Assuming the app is holding the restriction and could release it.

    The client relays the refusal and draws the band. It does not decide the outcome, so there is nothing on the device to change.

  • Tapping the resend control repeatedly while it is locked.

    The locked state already reflects a send that happened. Repeating the tap changes nothing that the countdown does not change on its own.

  • Treating a locked control as a sign that the address is unreachable.

    The lock reports the send, not the delivery. If the address itself was wrong, correcting it is the change that matters, and that address carries its own counter.

What to check when the resend control will not respond

Each item can be settled from the screen you are on.

  • Confirm the countdown is visible. A locked control with a countdown is reporting a send that already took place.
  • Check the address the screen is verifying, character by character, before spending the wait on it.
  • Do not restart the app to clear the lock; it persists across a restart.
  • Do not leave the screen and return expecting a fresh control; the lock is not tied to the screen being open.
  • If the address was wrong, change it rather than waiting: a different address has its own counter.
  • If an action was refused while the band was showing, note that the two are the same subject before reporting the action as broken.

Outside the scope of this page

The evidence here is what the mobile client displays and stores. The following are not part of it.

  • The list of operations that count as spending. It is decided on the server and is not readable from the client, so it is not given here in any form.
  • The duration of the resend lock, the length of a code, how long a code remains usable, and how many attempts are permitted. None of these are published on this page.
  • How you arrived at the unverified state from the registration form. That handoff is a separate subject and is not opened here.
  • Account removal and password problems. Neither is described on this page.
  • Any amount, package name, price or currency. Nothing on this page depends on a figure of that kind.
  • Server-side session rules of any sort. This surface reports only what the client draws and what it stores on the device.

Questions

Can I use the app before verifying my email address?

You can move around it. Verification is not what admits you: an unverified account is given the app together with a warning band. A spending attempt is refused by the server, and the app responds by showing the band and a path to have the code sent again.

Which actions are blocked while my address is unverified?

That is decided on the server and the client does not hold the list, so this page does not provide one. The app relays the refusal when it happens; it does not filter your actions in advance.

The resend button is locked and counting down. Was my code actually sent?

The lock follows a send. It was introduced precisely because the control used to report a send while the request was being skipped, so the locked state is now the honest report. Leaving the screen or restarting the app does not clear it.

I registered with the wrong address. Do I have to wait out the countdown?

No. The countdown is stored per email address, so verifying a different address starts a separate counter rather than continuing the one you are looking at.