Why an OfflineCreator generation cannot be cancelled

Cancellation is a pre-submission escape hatch

OfflineCreator's published `@offlinecreator/mcp` 0.1.2 tool server defines a narrow cancellation window: `cancel_generation` cancels a reserved generation before provider submit and refunds credits. The same tool server says text-to-image and text-to-video requests queue immediately, while image-to-video work uses a reserved generation that then needs `upload_input`. In practical terms, the documented cancelable case is that reserved image-input job before provider submission.

If the generation has already moved beyond that reservation, the public package does not document a way to interrupt provider work. Treat “cannot be cancelled” as a state-boundary result, not as permission to create a second cancellation attempt or assume another refund. Keep the original UUID, read its current state with `get_generation`, and choose the next action from that observation.

Verify the boundary with the existing generation ID

First call `get_generation` for the UUID you tried to cancel. A returned `reserved` state is consistent with the only cancellation case described by the published package: a job waiting before provider submission. For an image-input workflow, do not call `upload_input` or submit the generation if the operator has decided to cancel; call `cancel_generation` once and retain its structured response.

For any other returned state, do not describe the package as supporting cancellation. The public client exposes the cancel route as a POST request and turns a non-successful response into `StudioApiError` with the HTTP status and parsed response body. The MCP server then surfaces that error information. Preserve the exact status and sanitized details, but do not infer an undocumented route code or server-side transition from a generic client message.

Documented eligible state

reserved before provider submissionThe package describes cancellation and credit return only at this boundary.

Verification read

get_generation with the original UUIDRead state before retrying a state-changing tool.

Rejected cancellation

preserve status and parsed detailsDo not guess a route code or claim that active provider work was interrupted.

What the public evidence verifies and what it does not

The published 0.1.2 README lists `cancel_generation` among the package tools, and the published tool-server artifact describes that tool as cancelling a reserved generation before provider submit with a credit refund. The published client verifies the endpoint shape and error envelope. These public artifacts support the state rule readers need, but they do not publish the production route's exact response code for every ineligible state, its internal transaction ordering, or a promise that already-submitted provider work can be stopped.

This guide does not state an exact production error code, internal transaction sequence, or hidden state transition for an ineligible cancellation. Its decision path stays at the accessible public contract: cancel only the documented reserved pre-submit job; otherwise read status and continue through the appropriate status or failure workflow.

Avoid counting one reservation as two refunds

Cancellation and provider failure are different documented events. The package describes cancellation as refunding a reserved generation before submission. The live first-party MCP page separately says credits reserved for a generation return when that generation fails. If a reserved job is successfully cancelled, verify the current balance with `get_credits`; do not also wait for a second failed-job credit return or start a replacement based on an assumed bonus reversal.

The published `get_credits` tool returns the current Studio balance, not a transaction history. A single balance snapshot cannot identify which event changed it. For a defensible check, retain the generation UUID, the displayed model cost, a balance captured after reservation when available, the cancellation response, and a fresh balance. If those observations do not reconcile, stop before replacement work and send a sanitized record to support rather than repeatedly invoking cancellation.

Classify the observed state before choosing a recovery

A `reserved` image-input job that has not been submitted fits the documented cancellation rule. A `queued` or other nonterminal response is outside that published rule; preserve the ID and use bounded status checks rather than claiming that cancellation stopped provider work. The 0.1.2 wait client stops only at `completed` or `failed`, and a timed-out wait returns the latest state with `timedOut: true` instead of converting the generation to failure.

When the current state is `failed`, move to credit-return verification: the first-party MCP page says reserved credits return when a generation fails. A cancellation call that returns an API or MCP error is a failed state-changing request, not a new generation status. Keep its HTTP status and parsed details separate from the last successful `get_generation` response. This prevents a transport or authorization problem from being mislabeled as a provider cancellation.

Choose the next guide from the current state

Stay on this page when an image-input generation is still reserved before provider submission and the operator wants to abandon it. Use the failed-generation guide when the original record has reached `failed` and the question is whether the first-party failed-job credit-return rule was reflected in the current balance. If the reader's separate problem is an expired output URL, leave this cancellation page for the dedicated output-URL guide. Return to the troubleshooting directory when no reliable status can be read.

Keep this page limited to cancellation eligibility

This page owns one question: why `cancel_generation` is allowed for a reserved OfflineCreator generation before provider submission but is not documented as an interrupt for later provider states. It does not own stuck-job timing, failed-job credit verification, signed-output recovery, subscription cancellation, cash refunds, or payment disputes. It also does not promise a specific production error code for an ineligible cancellation.

Do not use community anecdotes to establish cancellation behavior on this page. Keep every product statement limited to the cited first-party product page and immutable public package artifacts. Preserve this route as an unreviewed, unpublished draft, and revalidate time-sensitive product claims under its monthly freshness cadence before editorial promotion.