can1357/oh-my-pi · error

Gemini Files API delete request failed

Error message

Gemini Files API delete request failed

What it means

Thrown by the Gemini provider's delete() when the fetch call itself throws — i.e. the DELETE request to the Gemini Files API never completed at the transport level (the library replaces the original error with this generic message). This is distinct from an HTTP error status (744), which means the request did complete.

Source

Thrown at packages/coding-agent/src/blob-broker/provider-files-gemini.ts:167

					headers: { "x-goog-api-key": credential },
				},
			};
		},
		async delete(handle: ProviderFileHandle): Promise<void> {
			if (handle.provider !== "google")
				throw new Error("Gemini Files API cannot delete a handle from another provider");
			const name = handle.id;
			if (typeof name !== "string" || !/^files\/[^/]+$/.test(name)) {
				throw new Error("Gemini Files API delete requires a valid file name");
			}
			let response: Response;
			try {
				response = await fetchImpl(`${GEMINI_FILES_RESOURCE_URL}/${name}`, {
					method: "DELETE",
					headers: { "x-goog-api-key": credential },
				});
			} catch {
				throw new Error("Gemini Files API delete request failed");
			}
			if (!response.ok) throw new Error(`Gemini Files API delete failed with HTTP ${response.status}`);
		},
	};
}

View on GitHub (pinned to 9690622007)

Solutions

  1. Check network connectivity and that generativelanguage.googleapis.com is reachable (curl the endpoint).
  2. Inspect proxy/firewall/VPN settings; configure HTTPS_PROXY if the environment requires it.
  3. Retry the delete with exponential backoff — deletes are idempotent, so a dropped request can safely be re-sent.
  4. If using a custom fetchImpl, log or wrap the underlying error to see the real cause (this library swallows it).
  5. Verify the request is not being aborted by an upstream AbortSignal that fires too early.

Example fix

// before: fire-and-forget delete that loses the real cause
await geminiClient.delete(handle);
// after: tolerate transient transport failures, delete is idempotent
try {
  await geminiClient.delete(handle);
} catch (err) {
  if (!/delete request failed/.test(err.message)) throw err;
  await Bun.sleep(1000);
  await geminiClient.delete(handle).catch(() => {}); // best-effort cleanup
}
Defensive patterns

Strategy: retry

Validate before calling

// reachability pre-check
const res = await fetch("https://generativelanguage.googleapis.com").catch(() => null);
if (!res) throw new Error("Gemini endpoint unreachable; skip delete");

Try / catch

try {
  await geminiClient.delete(handle);
} catch (err) {
  if (typeof err?.message === "string" && err.message.includes("delete request failed")) {
    // transport-level failure: safe to retry (delete is idempotent)
    await Bun.sleep(1000);
    await geminiClient.delete(handle).catch(() => {}); // best-effort cleanup
  } else throw err;
}

Prevention

When it happens

Trigger: Calling delete() when fetch throws: DNS failure, connection refused/reset, TLS errors, request aborted via signal, offline network, or a custom fetchImpl that rejects.

Common situations: No internet or firewall blocking generativelanguage.googleapis.com; corporate proxy requiring auth; DNS misconfiguration; deleting during process shutdown while the network stack is torn down; a custom fetchImpl with a timeout that fires.

Related errors


AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/dc32d7fc26f1546d. Report an issue: GitHub.