@chrischall/gemini-mcp 1.0.2 → 1.0.3

package/.claude-plugin/marketplace.json

@@ -7,7 +7,7 @@
   },
   "metadata": {
     "description": "MCP server for Google Gemini image generation and editing — generate and edit images via the Gemini API",
-    "version": "1.0.2"
+    "version": "1.0.3"
   },
   "plugins": [
     {
@@ -15,7 +15,7 @@
       "displayName": "Gemini Images",
       "source": "./",
       "description": "Generate and edit images with Google Gemini image models (Nano Banana / Nano Banana Pro) via natural language prompts",
-      "version": "1.0.2",
+      "version": "1.0.3",
       "author": {
         "name": "Chris Hall"
       },

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "gemini-mcp",
   "displayName": "Gemini Images",
-  "version": "1.0.2",
+  "version": "1.0.3",
   "description": "MCP server for Google Gemini image generation and editing — generate and edit images via the Gemini API",
   "author": {
     "name": "Chris Hall",

package/README.md

@@ -18,6 +18,7 @@ Developed and maintained by AI (Claude Code).
 | `GEMINI_INPUT_DIR` | No | Directory to resolve bare input-image filenames against (so `images: ["foo.jpg"]` works) |
 | `GEMINI_TIMEOUT_MS` | No | Upstream request timeout in ms (default: `60000`, or `120000` for `image_size: "4K"`); each generation tool also takes a per-call `timeout_ms` |
 | `GEMINI_HEARTBEAT_MS` | No | Progress-notification cadence in ms while a generation runs (default: `10000`; `0` disables) — keeps MCP hosts that reset their timeout on progress from timing out long generations |
+| `GEMINI_CHAIN_RETRY_MS` | No | How long to wait out interactions-store lag when a chained call 404s (default: `120000`; `0` disables retrying) |
 
 ### Long generations and client timeouts
 
@@ -28,6 +29,39 @@ anyway: the image is written to the output dir, `gemini_interact` also writes an
 `<image>.json` sidecar recording the `interaction_id`, and `continue_last: true` resumes the
 interaction the lost response belonged to.
 
+### When a chained call 404s
+
+A 404 on a request carrying `previous_interaction_id` is **not** proof the chain expired. The
+only 404 body observed live is generic — `"Requested entity was not found."` — and never names
+*which* entity. An unknown or renamed **model id**, and an expired Files API **`files/…` uri**
+(~48h TTL), return exactly the same thing. So the server no longer asserts a cause it can't
+establish: the upstream text is surfaced verbatim, and `gemini_interact` runs an experiment to
+find out which it was.
+
+Most often the id isn't missing at all — it just isn't *visible* yet. The interactions store is
+eventually consistent, and a freshly created id can 404 while the same id resolves fine minutes
+later; heavy turns (4K, Pro, `thinking_level: high`) are the likeliest to hit it, which is
+exactly the turn you most want to chain from. So a chained 404 is retried with exponential
+backoff for up to **120s** (`GEMINI_CHAIN_RETRY_MS`) before anything is declared broken. The
+404 generates nothing and isn't billed, so the wait costs only time.
+
+After that budget is spent, the tool looks up that id's sidecar, re-attaches the image it
+produced, and re-issues the request **without** the chain:
+
+- **The re-issue succeeds** → the chain really was the problem, and you get your image anyway,
+  reported as `chain_recovered: { expired_interaction_id, reanchored_on }`. The 404'd attempt
+  generates nothing, so this costs the one generation you'd have paid for re-anchoring manually.
+- **The re-issue 404s too** → the interaction id was never the cause. You get told exactly that,
+  with the upstream text, and pointed at the model id and any `files/…` uri instead of being
+  sent to chase an interaction that was fine all along.
+- **No sidecar matches the dead id** → the original error, rather than a guess. Re-anchoring on
+  the wrong picture would silently corrupt the edit.
+
+Separately, `continue_last` no longer dies with the server process: with no in-memory id it
+resumes from the newest `<image>.json` sidecar in the output dir and reports
+`continued_from_sidecar: true`. That case was never an expired chain at all — the interaction
+was alive upstream the whole time; only our memory of its id was gone.
+
 For hosts whose timeout can't be tamed (e.g. Claude Desktop, a fixed ~30s cap that ignores
 progress), two guards make re-issuing safe and unnecessary: