ElanoryaJewelry AI
The only legal version the server accepts is the one in its own build
You changed nothing, and registration, sign-in with Google or Apple, acceptance and generation all began to fail with the same unhelpful error. This page describes the comparison that produces it, and what the app never tells you.
What the server compares before it does anything else
Every request that carries acceptance of the legal documents also carries a version value. The server does not treat that value as information to record; it treats it as a condition. The route pins the field to the single value the server's own build carries, so a request holding a different value is refused before the rest of it is considered (apps/api/src/auth/auth.controller.ts).
This is why nothing done inside the app changes the outcome. The value is compiled into the install. An older build sends the value it was built with, the server compares it against the value it was built with, and when the two differ the request ends there.
The same route also checks a digest of the document text. Editing the contact or identity details printed inside a document changes that digest, and an older build then sends one the server no longer recognises. The effect of a digest change falls on client compatibility rather than on acceptance: whether an acceptance already recorded is still current is decided by the version value alone, so a digest change does not by itself put existing users back in front of an acceptance prompt, and why such a prompt appears at all is a separate question this page does not settle.
The requests this refusal reaches
The condition is not confined to the moment you accept something.
- Registration is refused.
- An account cannot be created from a build carrying the older value; the request is rejected at the route (apps/api/src/auth/auth.controller.ts).
- Sign-in with Google or Apple is refused.
- Provider sign-in carries the same governed field and meets the same comparison.
- Submitting acceptance is refused.
- The submission is itself one of the governed requests, which is why the acceptance screen is where many sellers first meet the failure.
- Generation requests are refused.
- The block does not stop at the entry screens; requests to generate are refused as well.
- What comes back is a generic invalid-request error.
- It carries no version, no build identifier and no instruction. Nothing in the response distinguishes it from any other malformed request.
Where the refusal reaches the screen
Attribution for every row: apps/api/src/auth/auth.controller.ts, read as static source. No request was sent and no running system was observed.
| What you were doing | What comes back | What decided it |
|---|---|---|
| Creating an account | An invalid-request error | The version value compiled into your build |
| Signing in with Google or Apple | An invalid-request error | The same value, checked on the same route |
| Accepting the documents | A failure to save | The submission is refused before anything is stored |
| Generating an image | An invalid-request error | The request carries the same governed field |
| Any of the above, after only the document text was edited | An invalid-request error | The digest your build sends is no longer one the server accepts |
What this costs while you are working
A morning of shooting is finished and the first request of the editing session is refused.
Check whether the failure is spread across sign-in and generation at once. That spread is the signature of a single condition, and reading it as one saves the time spent chasing two.
The acceptance screen reports a save failure, so the details are entered again.
Nothing is stored before the refusal. A second attempt from the same build sends the same value and is answered the same way.
The problem is escalated as a service outage.
State the shape rather than the cause: which requests fail, and what the message says. The source read here does not show the live state of any deployment.
A second device is added mid-session and cannot be signed in.
Registration and provider sign-in sit behind the same condition, so an older build is stopped at the entry point rather than partway through the work.
Why the two sides do not drift apart quietly
The text the app displays and the digest the server accepts are not two constants pasted by hand into two places. They are written by one generator, for both sides at the same time, and that is what makes a silent divergence between them structurally unlikely (apps/api/src/legal/legal-contract.ts, which records apps/jewelry-mobile/scripts/legal-manifest.mjs as the writer of both).
That is a statement about how the two files come into being, not a guarantee attached to every release. Whether the generator is actually run each time something changes is a matter of process and continuous integration; the code cannot enforce it, and this page does not claim that it does.
For a seller the consequence is narrow. When the two sides move, they are written to move together, so the mismatch you meet is between your installed build and the server it is talking to - not between two halves of the same build.
Questions this page leaves open
Everything above is a reading of source files. Nothing here observes a running system, and several ordinary questions cannot be answered from source at all.
- Which legal version is live in production, and which build is currently available in a store. The code shows a constant, never a live state.
- What the documents say, what they cover or what they give you. This page describes a mechanism and asserts nothing about the content of any text.
- Whether any particular text has been reviewed or published on a website. That surface is outside the code read here.
- When a newer build appears, by what route, or on what schedule. Nothing on this page is a release commitment.
- Purchases, restores and store billing failures, which are refused for their own reasons and are not governed by this comparison.
- Session behaviour, verification thresholds and any other parameter of the sign-in path.
Questions
Does this mean the service is down?
This page cannot tell you that, and neither can the source it rests on. What it can tell you is that a mismatch between the version value in your build and the value in the server's build produces exactly this failure - across registration, provider sign-in, acceptance and generation, as a generic invalid-request error and nothing more (apps/api/src/auth/auth.controller.ts).
Will the app tell me that it needs updating?
No. There is no update-required message on this path. The refusal returns as a plain invalid request, and on the acceptance screen it reads as a save that did not work. The absence of any prompt is the reason the failure looks causeless.
Only a contact detail inside a document changed. Why would that break anything?
The route checks a digest of the document text alongside the version value. Editing the printed text changes the digest, so an older build sends one the server no longer accepts. The effect lands on client compatibility; an acceptance already recorded is judged current by the version value, not by the digest (apps/api/src/auth/auth.controller.ts).
Can I find out which version the server is currently running?
Not from anything described here. The source shows the value a build carries, not what is deployed and not what a store is serving. Any statement about the live version would be outside this evidence, so none is made.