Crash-safe Sume submit: write the intent row and key first

Store the intent and the idempotency key before you submit to Sume, then store the job id after. A crash between those two writes is then harmless: on restart you resend the same request with the same key and Sume returns the original job instead of billing a second one.

Why the order matters

The job id only exists after the response, so you cannot store it first. The key you can. The docs say a retried submit with the same Idempotency-Key returns the original job, and that you must not submit a new paid job for the same intent just because a local process timed out.

import asyncio, os, sqlite3, uuid
import httpx

async def main() -> None:
    db = sqlite3.connect("jobs.db")
    db.execute("create table if not exists jobs(key text primary key, job_id text)")
    key = str(uuid.uuid4())
    db.execute("insert into jobs(key) values (?)", (key,))
    db.commit()
    headers = {"x-api-key": os.environ["SUME_API_KEY"], "Idempotency-Key": key}
    async with httpx.AsyncClient(base_url="https://api.sume.com", headers=headers) as c:
        r = await c.post("/v1/image-1.0/generate",
                         json={"prompt": "matte black bottle", "mode": "async"})
        r.raise_for_status()
        job_id = r.json()["request_id"]
    db.execute("update jobs set job_id=? where key=?", (job_id, key))
    db.commit()

asyncio.run(main())

On restart

Select rows with a key but no job id and resend each with its stored key. Reusing a key for the same payload is what the header is for; a different payload under the same key returns 409 idempotency_conflict, so store the payload or its hash with the row.

Related limit

A failed create releases its key, so a retry after a rejected request can proceed on the same key once you fix the request. Nothing is charged for a 4xx at create.