ElanoryaRuns and failures
Why a failed run is never tried again on its own
Your generation is queued for exactly one provider run. If that run fails, the job is finished: it does not go back into line, and a failure refunds. The retry wording that exists inside the code describes how the queue is paced, not a second attempt at your image.
One run, and then the job is over
When you submit a generation, the app puts one job on the queue and configures it with attempts: 1. That number is the whole story. Exactly one provider run takes place, and whatever comes back from it is final for that job.
If the run fails, the job does not return to the line. It ends as failed, and a failure refunds. There is no attempt left over to fall back on, which is why nothing changes while you wait.
The next provider run exists only if you start a new generation. That is the one action that produces another image.
What the code does with a failed run
Four of these describe the job itself; the last two describe classification and delivery, which are often mistaken for it.
- The job is queued with attempts: 1.
- Exactly one provider run is allowed per job, so a failed run has nothing behind it.
- A failure refunds.
- The job ends as failed and the credit is refunded. This page states nothing beyond that: no amounts, and no refund policy.
- A retry classification exists, but it is not about your job.
- Rate limits (429), provider server errors (5xx) and network errors are labelled retryable in the provider layer. The label is used for pacing, not for repeating your generation.
- A retry-after value slows the queue down.
- The value is handed to the limiter as a penalty, so work moves through more slowly. Your run has already ended by the time it applies.
- Some outcomes are labelled not retryable at all.
- A safety block, an incomplete response, and a response that comes back as text instead of an image are each classified as not retryable.
- In background removal, a result without transparency counts as a failure.
- An opaque passthrough is recorded as failed rather than delivered, so it is not treated as a finished result.
How each failure is classified, and what that changes
The classification lives in the provider layer. Read the third column carefully: in every row, your job is over.
| What came back | How the code classifies it | What the classification changes |
|---|---|---|
| Rate limit (429) | Retryable | The retry-after value penalizes the limiter, so the queue moves more slowly. Your job is not run again. |
| Provider server error (5xx) | Retryable | The same pacing effect. Your job is not run again. |
| Network error | Retryable | The same pacing effect. Your job is not run again. |
| Safety block | Not retryable | Nothing is repeated and nothing is slowed. The job ends. |
| Incomplete response | Not retryable | Nothing is repeated and nothing is slowed. The job ends. |
| Text returned instead of an image | Not retryable | Nothing is repeated and nothing is slowed. The job ends. |
How a failed run ends, step by step
This is the lifecycle of the job on the server, from submission to the point where it stops.
You submit the run
The app creates one job and puts it on the queue with attempts: 1.
The provider is called once
That single call is the entire run. What it returns decides the outcome of the job.
The failure is classified
The error is labelled retryable or not retryable. Retryable covers rate limits, provider server errors and network errors.
If a retry-after value came back, the queue is slowed
The value is given to the limiter as a penalty. It changes the pace of the queue, not the fate of your job.
The job ends as failed
There is no attempt left to fall back on, and a failure refunds.
Nothing further happens until you act
The next provider run exists only because you start a new generation.
Where this lands in a catalogue day
The direction of this page matters most when you are working through many pieces at once.
You assume a failed run will resolve itself, and the listing stays empty.
Treat a failed run as finished at the moment you see it, and start the run again yourself if you still need the image.
A rate-limited stretch reads as a set of your jobs waiting for another attempt.
It is not. The retry-after value slows the queue; no failed job of yours is sitting inside it waiting to be run.
You report a bad result expecting it to work as a retry or as a settlement.
The sheet states it directly: a report starts a content review; it does not automatically refund money or credits, and failed delivery is handled separately by the credit system.
You resubmit the same request repeatedly during a bad stretch.
A resubmission carrying the same idempotency key returns the generation you already have instead of starting a second one, so repeating the submission does not multiply the work.
What to do when a run comes back failed
In order, and none of it involves waiting.
- Read the result as final for that job: one provider run happened, and it is over.
- Decide whether you still need the image. If you do, start a new run yourself.
- Before you submit again, the review step shows the cost of the operation and the balance you are estimated to have left afterwards.
- If the image arrived but is wrong rather than missing, use the report sheet — it opens a content review, not a second run.
- If the run never started at all, that is a different state with its own causes and its own page.
What this page does not cover
Each of these is either owned by another page or is not something the app records.
- It does not say when a credit is spent or held during a run. That moment is covered on its own page.
- It does not state amounts, and it does not describe a refund policy or any store or money refund process. The registered fact is only that a failure refunds.
- It does not explain what a safety block responds to.
- It does not reproduce internal error text from the provider layer.
- It does not describe how the queue is arranged or who else is on it. The only effect stated here is that the queue slows down.
- It does not cover what the waiting screen shows, why a generation may refuse to start, or which finished jobs can be run again from their record. Each of those has its own page.
Questions
My generation failed. If I wait, will the app try again on its own?
No. The job is queued with attempts: 1, so exactly one provider run happens. When that run fails the job is finished and a failure refunds. A second run exists only if you start one.
The failure mentioned a rate limit. Doesn't that mean my job is waiting for another attempt?
No. Rate limits, provider server errors and network errors are classified as retryable, and a retry-after value is handed to the limiter so the queue moves more slowly. That classification paces the queue; it does not run your job again.
What happens to the credit for a run that failed?
A failure refunds. This page does not state amounts and does not describe a refund policy; when a credit is spent during a run is covered on its own page.
Does reporting a bad result start a new run?
No. The report sheet states it in plain words: a report starts a content review; it does not automatically refund money or credits, and failed delivery is handled separately by the credit system.