Recover from an expired generation output URL

Request completed status through the owner-signing path

At first-party Studio commit `81ad295`, `getGenerationStatus` calls `findGeneration` with the supplied generation ID and requesting user ID. `findGeneration` enforces that pairing in both storage paths: the demo record must have the same user ID, and the SQL query requires both `id` and `user_id`. If no account-bound generation is found, status handling returns `NOT_FOUND`. For a terminal completed record, the function passes the generation payload to `withSignedOutput`; failed records take the same helper path but remain unchanged because they are not completed.

For a completed payload, `withSignedOutput` tries `createOwnerDownloadUrl` with the generation ID and output kind. In the configured signing path, that function calculates expiry from invocation time, signs the generation ID, expiry, kind, and owner marker, and returns the URL plus expiry fields. If signing or required configuration throws, `withSignedOutput` catches the failure and returns the original payload instead. The normal configured path explains a fresh short-lived owner URL; it is not an authenticated production recovery result, deployment-parity finding, SLA, or availability guarantee.

Lookup key

The original generation IDDemo storage checks the record user and SQL requires both generation ID and user ID.

Implementation result

Signed `outputUrl` and expiry fields on signing successSigning or configuration failure falls back to the original payload; production usability still requires an authenticated test.

Interpret only what the status response proves

Use the same generation ID with `get_generation` or `download_output`. The first-party service calls a lookup whose demo branch checks the record's user ID and whose SQL branch filters on both generation ID and user ID. A terminal completed status invokes the signing wrapper, while a missing account-bound record produces `NOT_FOUND`. The implementation establishes that request path; it does not establish why any particular production lookup failed.

At the public package layer, `download_output` returns an error with the observed status when the payload is not completed with a string `outputUrl`. When completed output metadata is present, it forwards the URL and expiry fields. Other API failures are surfaced as structured status and parsed body details. Do not infer scope, transport, deletion, billing, or another cause unless the returned error and a separate supported source establish it.

Completed with URL

Test the response URLA returned URL is not, by itself, evidence that the backend regenerated it or that the download will succeed.

Not completed

Preserve the included statusThe public server returns an error instead of an output-download result in this branch.

API error result

Record status and parsed detailsDo not assign a root cause that the returned fields and cited sources do not prove.

Run a bounded MCP check

First, recover the exact `generationId` from an existing record you control. Second, supply that ID to `get_generation`; the Studio lookup requires it to match the requesting user in demo storage or SQL. For a completed record, the signing wrapper attempts owner URL creation during that status request. On configured signing success it returns signed output metadata; on signing or configuration failure it returns the original payload. Third, attempt any returned signed URL once and record the response fields and download outcome. The normal implementation path supports the immutable promise, while only a successful request establishes usability in the environment tested.

The public client validates the generation ID as a UUID before requesting `/api/v1/generations/{id}`. It keeps Studio API requests under `/api/v1/` and exposes absolute output URLs only when their origin matches the configured Studio API origin. If that check fails, it removes `outputUrl` and adds `outputUrlError`. Preserve that observed error rather than claiming the rejected URL was safe or usable.

Step 1

Confirm the generation IDDo not substitute a prompt, filename, provider request ID, or URL token.

Step 2

Fetch statusRecord completion and the response's URL-expiry metadata when present.

Step 3

Test once and record the resultOnly an actual successful request establishes that the returned URL was usable during the test.

Verify the response without overstating it

Check `completed` status, `outputUrl`, `outputContentType`, and whether `outputUrlExpiresAt` and `outputUrlExpiresInSeconds` are present. In the configured signing path, the first-party helper computes expiry from current time on invocation and signs that expiry into the owner URL. If signing or configuration fails, the wrapper returns the original payload, so expiry fields are not unconditional. Do not require the package's `get_generation` wrapper to add fields beyond the backend payload; `download_output` inserts its supplied generation ID into its own result. This page publishes no production timing SLA and does not claim that separate calls always produce unique token text.

The Studio product page states that generated outputs remain behind authenticated account access by default unless a generation is deliberately shared to the Community gallery. The public support guide separately says to remove credentials and private media from reports. Following that documented minimum, provide environment details and sanitized error text; do not attach private output media or credential material. The reviewed sources do not explicitly classify a signed output URL as a bearer credential, so this page does not make that stronger claim.

Positive check

Completed status and expected output metadataThese observations describe the response but do not establish regeneration or download success.

Support minimum

Environment details and sanitized error textRemove credentials and private media as required by the public package support guide.

Separate expiry from look-alike failures

The service and public client expose distinct outcomes without proving every root cause. A demo record with a different user or a SQL lookup without the same `id` and `user_id` is not returned, after which status handling produces `NOT_FOUND`. A completed record invokes the signing wrapper; successful signing adds owner URL metadata, while signing or configuration failure returns the original payload. A `download_output` invocation without completed status and a string URL returns the documented not-completed error plus status. An absolute output URL on an unrelated origin is omitted and replaced with `outputUrlError` by the client.

For any non-success API response, the client records the HTTP status and parsed body in `StudioApiError`, and the server returns those fields as error details. Capture whether the observed failure came from opening a URL, calling `get_generation`, or calling `download_output`, then preserve the exact sanitized result. Do not reinterpret a status code as OAuth failure, account mismatch, object deletion, refund eligibility, or proof that a replacement generation is required without separate supporting evidence.

Completed response includes URL

Attempt and observeThe public source proves field forwarding, not URL regeneration or usability.

API request fails

Preserve status and parsed bodyUse only the cause stated by supported error evidence.

`outputUrlError` appears

Preserve the origin-safety errorDo not reconstruct or approve the rejected external URL manually.

Choose the next guide from the failed operation

Stay on this page when the generation-and-user lookup succeeds, completed status reaches the signing wrapper, and configured signing returns owner URL metadata. If signing falls back to the original payload, the lookup returns `NOT_FOUND`, or the MCP call fails elsewhere, use the observed fields and the general troubleshooting directory without assuming a cause. The cancellation guide is a separate next action for cancellation questions; cancellation is not presented as an expired-link remedy.

Editorial ownership and evidence boundary

This page owns the implementation-backed expired-link explanation: `findGeneration` requires the generation-and-user match, completed status reaches `withSignedOutput`, and the configured signing path invokes owner URL creation using expiry calculated from current time. Successful signing returns the signed URL and expiry metadata; signing or configuration failure falls back to the original payload. It does not claim to repair OAuth, scopes, transport, cancellation, refunds, or provider timing. Revalidate these implementation claims monthly.

The research did not access a production account, signed output, private object, API key, OAuth token, or browser cookie. It did not intentionally let a real link expire or execute an authenticated recovery. It therefore does not independently measure production recovery, token uniqueness, deployment parity, or availability, and it publishes no production timing SLA. Recent community coverage for this exact symptom was also insufficient.