Jewelry AI - store screen

A restore that reports success has only reported that the call did not fail

Tapping Restore Purchases runs the store provider's restore call, waits for it, and then refreshes your wallet from the server. Unlike a purchase, nothing in that sequence checks whether your balance changed, so the message you get back describes the call rather than the outcome.

What the button runs, in order

Restore Purchases is wired to two operations that happen one after the other. The screen calls the store provider's restore and awaits it; when that call returns, it refreshes your wallet from the server. Both are visible in apps/jewelry-mobile/src/app/store/index.tsx, where the awaited restore call is followed by the wallet refresh.

A purchase is treated differently. It is confirmed against the change in credit before the screen reports anything back to you. The restore path carries no equivalent check: at no point does it compare the wallet as it stood before the call with the wallet as it stands after.

What follows is narrow but exact. If the call comes back without an error, the success message is shown. The message describes the call. It does not describe your account, and it was not derived from your account.

Why the link is sometimes unpressable

The restore control does not decide its own availability. It shares an enabled state with the rest of the store screen.

The link is disabled unless store offers are ready.: The disabled condition on the control in apps/jewelry-mobile/src/app/store/index.tsx reads availability !== 'ready' || busy. When offers cannot be loaded, the restore link stays closed along with the rest of the screen. The same condition also holds restore closed while a purchase is still running, which is behaviour belonging to the purchase flow and is not examined here.
A user who cannot get offers cannot start a restore either.: The two are bound together at the interface. A screen that failed to present its offers is also a screen on which the restore cannot be started, however unrelated the two things are.
The dependency is an interface gate, not a technical requirement.: The restore logic itself does not depend on offers having loaded. The requirement lives only in the button's disabled condition, which is a property of the screen rather than of restore.
Why the offers failed to load is a separate question.: It has its own cause, it belongs to another page, and it is not re-derived here.

Reading your own screen after a restore

The flow gives you two things to read. This is how they relate to each other.

Situation	Choose	Why
The message reported success and the wallet reading differs from the one you noted.	Treat the screen reading as the outcome.	The wallet is re-read from the server after the call, so the value on the screen is a fresh server reading, while the message only reports that the call did not error.
The message reported success and the wallet reading is unchanged.	Do not read the two as a contradiction.	The message was produced by a call that returned without an error. It was never a claim that a balance had moved.
The restore link cannot be tapped.	Establish the state of the store screen before drawing any conclusion.	The control is disabled while offers are not ready, which means the flow never ran and nothing about the account has been tested.
You want to know what the store returned for a particular kind of product.	Treat that as outside this page.	What was verified is the call our screen makes and the refresh that follows it, not the store provider's own behaviour.

The flow, stage by stage

Each stage runs something, and each stage checks less than the stage after it appears to promise.

Stage	What happens	What is checked
Link state	The control is enabled only while store offers are ready	Offer availability, before anything runs
Restore call	The store provider's restore runs and the screen waits for it	Whether the call returned an error
Wallet refresh	The wallet is re-read from the server	Nothing is compared against the earlier reading
Message	A success message is shown	Nothing beyond the absence of an error

Before you conclude that nothing came back

Five checks that keep the message, the screen and your account apart from one another.

Confirm the restore link was actually pressable at the moment you tapped it.
Note the wallet reading before the tap; the refresh afterwards is only useful against a prior reading.
Read the message as a statement about the call, not about your account.
Compare the two wallet readings rather than comparing two messages.
Keep the question of why offers failed to load separate from the question of what restore did.

What this page does not settle

The behaviour above was read from one screen in the app. Everything below sits outside it.

What the store provider itself returns, and how it treats different kinds of product. That is internal store behaviour and was not part of what was verified.
How, in what order, or how quickly credit is created on the server after a payment. Only the client's waiting and display behaviour was examined.
Why store offers failed to load. That has its own cause and belongs to another page.
What a purchase that cancels or fails does. That flow is examined separately.
The behaviour of the wallet and transaction history screen, which was not part of this examination.
Anything about prices, amounts, plans or currency. None of that is in scope on this page.

Questions

Does Restore Purchases give back credits?

What was verified is that the button runs the store provider's restore call and then re-reads your wallet from the server. Whether anything returns is not confirmed by the flow and is not something this page can state. The success message only reports that the call did not error.

The restore link is greyed out. Is something wrong with my account?

The control is disabled while the store screen's offers are not in a ready state, so a greyed-out link is about the screen rather than about your account. Until the link is pressable, nothing has been tested.

It said the restore worked, but nothing on the screen changed. Did it fail?

The message is shown when the call returns without an error, so an unchanged screen does not contradict it. The wallet reading, taken before and after, is the comparison that carries information.

I am setting up a new phone. What does running a restore tell me?

It tells you that the call ran and did not error, and it leaves you with a wallet value freshly read from the server. It does not tell you what the store returned, which is outside the surface this page was written from.