ElanoryaJewelry AI · failure messages
The failure sentence classifies the error, it does not diagnose your photo
When a run fails you never see the provider's own error text. That text is matched against three keyword groups, with a fourth outcome for everything else, and the match decides the sentence on your screen.
The sentence you read is picked by a keyword match
When a generation fails, the app does not put the provider's error in front of you. The failure text is run through a mapping that checks it for keyword groups and returns one of four outcomes (store.tsx:2360-2375, verified 2026-08-18). The sentence on your screen is that outcome.
This is why the wording feels both confident and vague at the same time. The mapping is classifying a string. It is not inspecting your jewelry photograph, your model photograph or your account, because none of those are its input.
Two consequences follow. Failures with very different underlying causes arrive as the same sentence whenever their text falls in the same keyword group. And a failure can arrive as generic purely because its wording matched nothing the mapping looks for.
The four buckets, and what routes into each
Read the middle column as the outcome name used in the code, and the right column as the honest reading of it. Mapping verified in store.tsx:2360-2375 on 2026-08-18.
| What the failure text contains | Outcome it maps to | What that outcome does and does not tell you |
|---|---|---|
| timeout, stuck-timeout, or "zaman asimi" | timeoutRefunded | The failure text mentioned a timeout. It does not report how long the server actually took. |
| nsfw, safety, or blocked | contentBlocked | The failure text carried a safety word. Why a provider's safety layer fired is outside what this page can state. |
| quota, rate limit, or 429 | serviceBusy | The failure text mentioned a quota or a limit. It does not report how full the queue was. |
| none of the three groups above | generic | The failure text matched nothing the mapping looks for, so the sentence carries no cause at all. |
Reading each of the four sentences
One row per outcome, plus the decision that follows all of them. Each row states only what the mapping supports.
| Situation | Choose | Why |
|---|---|---|
| You got the timeout sentence. | Read it as: the failure text contained a timeout keyword. | timeout, stuck-timeout and "zaman asimi" are the strings that route there (store.tsx:2360-2375). The sentence carries no measurement of the server's actual duration. |
| You got the content-blocked sentence. | Read it as: the failure text carried a safety word. | nsfw, safety and blocked are the strings that route there (store.tsx:2360-2375, verified 2026-08-18). Why a provider's safety layer fired is not stated by the sentence and is not explained on this page. |
| You got the service-busy sentence. | Read it as: the failure text mentioned a quota or a rate limit. | quota, rate limit and 429 are what route there. How busy the service actually was is not carried in the sentence and is not claimed here. |
| You got the generic sentence. | Read it as: nothing matched. | Generic is the fall-through, so it tells you only that the failure text fell outside all three keyword groups. |
| You are deciding whether to submit the same piece again. | Decide it yourself; nothing is waiting to run again on your behalf. | A submission is exactly one provider run and a failure refunds (generation-queue.ts:39, verified 2026-08-18). |
What holds whichever sentence you get
Four statements that do not depend on which bucket your failure landed in.
- The run is over and its credit comes back.
- One submission is one provider run, there is no automatic retry, and a failure refunds (generation-queue.ts:39, verified 2026-08-18).
- A retryable label exists in the worker, and it is not about your job.
- Provider errors classified as retryable slow the queue through a limiter penalty rather than re-running your submission (model-generate-provider.ts:280-284, verified 2026-08-18) — that mechanism has its own page and is not re-derived here; see the related reading below.
- Some outcomes are labelled not retryable at all.
- A safety block, a missing response, and a reply that comes back as text instead of an image are all classified as not retryable in the worker (model-generate-provider.ts:296, 310, 317, verified 2026-08-18).
- The sentence is the whole of what a release build shows you.
- The unmapped error detail is rendered only in development builds (result-screen.tsx:383-387, verified 2026-08-18).
Three ways the sentence gets misread
Each of these turns a classification into a conclusion the classification cannot support.
Reading the content-blocked sentence as a verdict on the piece, and re-shooting it.
The mapping's input is the failure text, and the words nsfw, safety and blocked are what route to that outcome (store.tsx:2360-2375). It is not the output of looking at your image.
Reading the service-busy sentence as a queue report and pausing a batch on that basis.
quota, rate limit and 429 are what route there. Neither the message nor this page states a queue state, so a batch decision made on it rests on nothing.
Reading the generic sentence as a specific error deliberately withheld.
Generic is the fall-through for text that matched no keyword group; it is the mapping being as precise as its four outcomes allow.
What the sentence cannot tell you
Boundaries of this page, stated as limits rather than left to inference.
- Why a provider's safety layer fired. The provider model's internal behaviour is outside what this page can check or explain.
- How long the server actually took on your run, or how deep the queue was when it failed.
- Which worker-side outcome produced which sentence. The worker's retryable classification and the four-bucket message mapping are two separate classifications, and nothing here connects one to the other.
- Whether the same photograph would end differently on a second submission.
- What a refund is worth or how billing works. Amounts and policy are not covered on this page.
- Which of the four sentences an opaque background-removal passthrough produces.
Questions
Does the failure message tell me what was wrong with my photo?
No. The message is selected by matching keywords in the failure text (store.tsx:2360-2375, verified 2026-08-18), so it reports which group that text fell into. Your photograph is not an input to that decision.
The message said the service was busy. Does that mean the queue is long?
It means the failure text contained quota, rate limit or 429, which is what routes to that outcome. How busy the service actually was is not carried in the sentence, and this page does not claim it.
Can I see the provider's own error text?
Not in a release build. The unmapped error detail is rendered only in development builds (result-screen.tsx:383-387, verified 2026-08-18); what you read is the mapped sentence.
Background removal reported a failure. Was the run still charged?
A failed run refunds its credit (generation-queue.ts:39). In background removal specifically, a result that comes back without transparency counts as failed and is refunded on the same rule (background-remove-provider.ts:10). Which sentence accompanies that outcome is not something this page can state.