Wait for an OfflineCreator generation from the CLI

Choose the supported wait path

The CLI can wait only as part of a new submission: `npx @offlinecreator/mcp generate ... --wait` invokes bounded polling when the started response does not require an upload. The current parser has no standalone `wait` subcommand and cannot attach its CLI wait path to an existing UUID. Existing jobs and upload-required workflows need the MCP `wait_generation` or status tool, or the public API.

Use this page as a boundary and timeout guide, not as documentation for an absent command. Reject a bare `wait` token before process launch, because the parser's unknown-command path prints help and returns failure. For `generate --wait`, persist the returned UUID and distinguish `completed`, `failed`, and `timedOut: true` before choosing any later MCP or API action.

Understand the polling bounds

The public client defaults to a 120-second timeout and a 1.5-second interval. It queries one generation repeatedly and returns when status becomes `completed` or `failed`. If the deadline passes, it performs one final status read and returns that payload with `timedOut: true` plus an error message when needed. This bounded behavior prevents an endless loop.

Route newly submitted non-upload work through `generate --wait`, but route an already known UUID through the MCP wait or status tool. Test the command token before launch: the parser has no `wait` case, so accepting that spelling would turn help text and a failure status into a false polling result.

Treat timeout as an observation, not a terminal state

A timed-out wait does not cancel the job and does not prove that processing failed. Store the generation UUID, leave the original work intact, and resume status checks later through the MCP/API surface. Only `completed` and `failed` are recognized as terminal by this client helper. A timeout result alone does not justify starting a separate generation; query the known UUID before deciding what to do next.

Let the client deadline bound one observation window, not the lifetime of the remote job. Its default loop sleeps 1.5 seconds between reads and performs a final read after 120 seconds. Store that final payload and schedule the next observation separately instead of nesting an unbounded shell loop around the command.

Handle upload-required work separately

The CLI checks `uploadRequired` before entering its wait helper. If `generate --wait` returns the started response immediately, inspect that flag instead of treating the quick exit as completion. The parser establishes only that its CLI wait helper is skipped for upload-required responses; it does not document the remaining upload workflow.

Use three result branches: completed can advance to retrieval, failed can surface its recorded error, and timed out remains unresolved. Keep the UUID in every branch. This mirrors the statuses recognized by the public wait helper and avoids labeling a still-running generation as failed solely because the local foreground window ended.

Log state without exposing credentials

Record UUID, last observed status, poll start and stop timestamps, package version, and whether the client reported a timeout. The npm registry listed `@offlinecreator/mcp` 0.1.2 on August 9, 2026, but log the version actually installed rather than assuming the registry release. Keep the API key in environment secret storage and out of shell tracing. On errors, preserve a sanitized diagnostic and query the known job before retrying. The recent web corpus for this narrow command was unrelated and several social sources failed, so no community timing estimate or claimed typical completion duration is used here.

For an upload-required start response, persist the UUID and do not interpret the immediate return as completion. The parser establishes only that `generate --wait` skips the CLI wait helper when `uploadRequired` is set; consult the separately documented attachment workflow instead of inferring upload or submit steps from that guard.

Related reading