Diagnose a generation that remains processing
Use bounded status checks and separate provider delay from a terminal failure.
The immutable 0.1.2 package README identifies `get_generation`, `wait_generation`, and `list_generations` among the published tools. For one observation, call `get_generation` with the existing `generationId`. For bounded observation, call `wait_generation` with that same ID and an explicit finite `timeoutSeconds`. Use `list_generations` when the ID must first be recovered from the account's recent jobs. None of these read actions requires creating replacement work.
Do not paste an API key, OAuth token, cookie, prompt, source image, or signed output URL into a diagnostic command or ticket. A safe handoff identifies the tool and transport but redacts credentials and private creative inputs. If the generation ID itself is treated as sensitive in your environment, share it only through the authorized support channel.
- One observation
- get_generationUse the existing UUID and inspect the status returned by Studio.
- Bounded observation
- wait_generationSupply the existing UUID and a finite timeout; do not create a new generation.
Treat processing as nonterminal, not as proof of failure
Start with the generation ID that the accepted request returned. The published `@offlinecreator/mcp` 0.1.2 client reads the returned status as text and stops its wait loop only when that value is `completed` or `failed`. Any other returned value keeps the same generation in the loop until the caller's time bound is reached. Record the exact observed value instead of rewriting every nonterminal response as “stuck” or failed.
A wait timeout is also a client boundary, not a terminal job state. The published `@offlinecreator/mcp` 0.1.2 client performs one final status read when its wait window expires, returns that latest status, and adds `timedOut: true`. Keep that generation ID and continue with bounded reads. Do not start a replacement merely because an MCP tool stopped waiting.
- Continue observing
- Any returned status other than completed or failedPreserve the exact wording and generation ID; the published wait loop treats that value as nonterminal.
- Stop polling
- completed or failedA terminal response changes the next action from waiting to retrieval or failure review.
- Do not infer failure
- timedOut: trueThe package returns timeout metadata alongside the latest status rather than converting the job to failed.
Use one bounded status timeline
1. Save the accepted generation ID, model ID, interface, and UTC start time. 2. Make one status read with `get_generation`. 3. If the result is nonterminal, choose a finite observation window and avoid parallel waiters for the same ID. 4. Stop immediately on `completed` or `failed`. 5. If the window ends first, save the latest status and `timedOut` marker, then move the ID to a slower follow-up queue or the account library instead of submitting again.
The public package supplies concrete bounds. Its client defaults to a 120-second wait and a 1.5-second poll interval. The standalone `wait_generation` tool accepts `timeoutSeconds` from 5 through 300. `generate` with `wait: true` uses 120 seconds, while image-input submission with waiting uses 180 seconds. These are caller wait limits, not promised provider completion times. Network and API latency also mean the number of reads is not an exact clock-derived total.
- Default package wait
- 120 secondsThe client returns the latest status with timeout metadata when the window ends.
- Standalone tool range
- 5 to 300 secondsSelect a finite timeout that fits the operator's workflow; the range does not guarantee completion.
- Default poll interval
- 1.5 secondsAvoid adding another independent waiter for the same generation.
Separate provider delay from status-read failure
A successful status response with a value other than `completed` or `failed` means the published client will continue its bounded wait. By contrast, a non-successful API response causes that client to throw `StudioApiError` with the HTTP status and parsed response body. The published MCP tool server converts that exception into an error result containing the message, status, and body details. Preserve those fields separately from the last generation state; an error reading status is not a returned `failed` state.
After a read error, follow only an explicit retry instruction present in the sanitized response or move the existing ID to a later bounded check. Do not infer a provider outcome, a refund, or a safe replacement from transport failure alone. The public package artifacts establish how the client surfaces the error, but they do not establish one universal recovery delay for every server, proxy, or network failure.
OfflineCreator's live first-party MCP page says MCP and CLI are interfaces to the cloud Studio service and use the same account credit balance, model costs, moderation, and automatic-failure-refund rules as the browser workflow. That clarifies the boundary: an MCP timeout is not a separate local rendering process, and reconnecting the client does not create an independent provider job ledger.
- Status read succeeds
- Classify the returned generation stateContinue only while the state remains nonterminal and the observation window remains open.
- Status read errors
- Classify HTTP or MCP evidence firstRetry the read according to its explicit instruction; do not infer a terminal provider outcome.
Verification scope and known limits
This runbook was verified on 2026-08-09 against immutable public `@offlinecreator/mcp` 0.1.2 client, tool-server, and README artifacts plus the live first-party MCP page. The immutable package client establishes the 1.5-second default poll interval, 120-second default timeout, final-read timeout response, terminal `completed` or `failed` check, and non-success error shape. The package server establishes the standalone 5-to-300-second timeout range, the 120- and 180-second tool-specific waits, and the MCP error-result mapping.
No authenticated production generation was started for this research, and no account balance, private media, provider request, or production credential was accessed. Therefore this page does not claim a normal completion duration, a maximum provider runtime, or a percentage of jobs that recover after a timeout. If the generation remains nonterminal beyond the operator's chosen follow-up window, preserve the evidence and escalate rather than inventing a universal cutoff.
- Package evidence
- @offlinecreator/mcp 0.1.2Immutable published client and tool-server files were retrieved directly.
- Unverified
- A universal provider completion deadlineNo benchmark or production timing sample was collected.
Choose the next guide from the observed boundary
Stay on this page when an accepted generation ID keeps returning a nonterminal state or when a bounded wait returns `timedOut: true`. Use the rate-limit guide when a status read returns 429 instead of a generation state. Use the failed-generation guide only after the job reports `failed` and the next task is to verify its credit outcome. Return to the troubleshooting directory when authentication, transport, or tool discovery fails before a usable generation status can be read.
Editorial ownership boundary
This page owns only an accepted OfflineCreator generation that remains nonterminal: the package's terminal checks, polling bounds, timeout interpretation, and separation of a returned state from a status-read error. It does not own 429 recovery, failed-job credit verification, cancellation eligibility, expired output links, authentication, or general MCP transport repair. Revalidate current product statements monthly; consolidate this page into the troubleshooting directory if status checks and bounded polling can no longer be verified.