{"slug": "why-an-ai-image-generation-timeout-should-not-automatically-trigger-a-retry", "title": "Why an AI Image Generation Timeout Should Not Automatically Trigger a Retry", "summary": "A developer working on the Nano Banana 2.1 image-generation adapter argues that automatic retries on a timed-out image-generation request can trigger a second paid job, since a provider may have already accepted the original submission. The adapter therefore performs a single creation request, validates that a usable prediction ID is returned, and separates submit() from poll() so status checks can be repeated safely while submissions are not. The writeup also notes that a 'succeeded' status is validated by checking for an HTTPS URL and that raw provider error bodies, which may contain prompts or reference-image URLs, are not copied into failure messages.", "body_md": "An image-generation request can time out even after the provider has accepted the job.\n\nThat creates an awkward situation: the application has no result, but another generation may already be running. Automatically repeating the request can create a second paid job.\n\nThis article examines that boundary using the current provider adapter in [Nano Banana 2.1](https://nano-banana-2-1.com/), a project I work on. It describes implementation choices and remaining failure cases, not a claim that every recovery scenario is solved.\n\nThe adapter exposes two operations:\n\n`submit()` creates a prediction and returns its identifier.`poll()` reads the status of that existing prediction.\nA simplified version of the interface looks like this:\n\n```\ninterface ImageProvider {\n  submit(request: ImageRequest): Promise<{ taskId: string }>;\n\n  poll(taskId: string): Promise<\n    | { status: \"pending\" }\n    | { status: \"completed\"; imageUrl: string }\n    | { status: \"failed\"; error: string }\n  >;\n}\n```\n\nThis separation matters because the operations have different consequences.\n\nRepeating a status request asks about the same job. Repeating submission may create another job.\n\nThe adapter performs a single creation request and validates that the response contains a usable prediction ID. It does not contain an automatic retry loop around that POST.\n\nConsider this sequence:\n\nThe application cannot safely infer that nothing happened.\n\nAvoiding an automatic resubmission reduces duplicate-job risk, but it leaves a recovery problem: without the ID, the application cannot use its normal polling path.\n\nA more complete recovery design would need a documented provider idempotency mechanism or another way to reconcile the original request. Those capabilities should be verified rather than assumed.\n\nA `succeeded` status is not enough by itself.\n\nIn this adapter, the output can be a URL string or an array. The code selects the first array entry when necessary, then checks that the result is an HTTPS URL.\n\nMalformed output becomes an explicit error instead of an apparently successful generation with an unusable result.\n\nThat check is only basic validation. It does not prove the URL is reachable, contains a valid image, or has been copied into application storage.\n\nProvider error bodies can contain prompts or reference-image URLs.\n\nFor failed predictions, the adapter keeps a small operational error containing the provider, processing stage, category, and failure code. It does not copy the provider's raw error body into the returned failure message.\n\nThis preserves enough information to classify the failure without unnecessarily duplicating user input.\n\nUseful tests for this design include:\n\n`pending`.\nThe main design lesson is to distinguish “the request failed” from “the work never started.” In an asynchronous, paid workflow, those are different states.\n\nDisclosure: This article was drafted with AI assistance using the project's current source code. The interface example is simplified for explanation.", "url": "https://wpnews.pro/news/why-an-ai-image-generation-timeout-should-not-automatically-trigger-a-retry", "canonical_source": "https://dev.to/dong_45bfc981cf912828e/why-an-ai-image-generation-timeout-should-not-automatically-trigger-a-retry-kp1", "published_at": "2026-10-08 08:39:53+00:00", "updated_at": "2026-10-08 08:48:44.370467+00:00", "lang": "en", "topics": ["ai-tools", "generative-ai", "ai-infrastructure"], "entities": ["Nano Banana 2.1"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/why-an-ai-image-generation-timeout-should-not-automatically-trigger-a-retry", "markdown": "https://wpnews.pro/news/why-an-ai-image-generation-timeout-should-not-automatically-trigger-a-retry.md", "text": "https://wpnews.pro/news/why-an-ai-image-generation-timeout-should-not-automatically-trigger-a-retry.txt", "jsonld": "https://wpnews.pro/news/why-an-ai-image-generation-timeout-should-not-automatically-trigger-a-retry.jsonld"}}