GEMINI LABJP
PRO35 — July 17, the date reports had pointed to, has passed without an official Gemini 3.5 Pro announcement or model card. July 24 is being cited as the fallbackNB2LITE — Nano Banana 2 Lite, otherwise known as Gemini 3.1 Flash-Lite Image, arrives as the fastest of the family: roughly four seconds per image at $0.034 per thousandOMNI — Gemini Omni Flash enters public preview, generating video up to ten seconds long at $0.10 per second of outputEDIT — Omni Flash is built around conversational editing. Swap a character, relight a scene, or change the angle in plain language, and the original audio and video tracks stay intactSYNTHID — Both new models carry SynthID watermarking, so anything they produce can be checked for provenance from inside the Gemini appSHUTDOWN — The older image generation models are deprecated and switch off on August 17. Worth checking your migration windowPRO35 — July 17, the date reports had pointed to, has passed without an official Gemini 3.5 Pro announcement or model card. July 24 is being cited as the fallbackNB2LITE — Nano Banana 2 Lite, otherwise known as Gemini 3.1 Flash-Lite Image, arrives as the fastest of the family: roughly four seconds per image at $0.034 per thousandOMNI — Gemini Omni Flash enters public preview, generating video up to ten seconds long at $0.10 per second of outputEDIT — Omni Flash is built around conversational editing. Swap a character, relight a scene, or change the angle in plain language, and the original audio and video tracks stay intactSYNTHID — Both new models carry SynthID watermarking, so anything they produce can be checked for provenance from inside the Gemini appSHUTDOWN — The older image generation models are deprecated and switch off on August 17. Worth checking your migration window
Articles/API / SDK
API / SDK/2026-06-24Advanced

When a Deploy Drops the Webhook: Reconciling Gemini Long-Running Operations with a Belt-and-Suspenders Design

Even after you move from polling to Webhooks, events still get dropped during deploys and transient 5xx windows. Here is how I double up Gemini long-running operations with an operation ledger and a low-frequency reconciliation poller so a missing terminal event never goes unnoticed.

Gemini API190Webhooks2Long-Running OperationsBatch API5Reliability4

Premium Article

One morning, a nightly batch I run for a personal project simply hadn't written its results back. The logs were clear: the Batch API job itself had succeeded. But the webhook that announced completion arrived at the exact moment a redeploy was rolling out. The receiving Worker swapped out for a fraction of a second, and that single delivery slipped through.

This was shortly after I had retired polling in favor of Webhooks. The move to event-driven was the obvious one — no more wasteful status checks — but it quietly introduced a new failure mode: if you miss the event, nobody notices.

This is a record of the belt-and-suspenders design I built so that never happens again. The example uses Gemini long-running operations (Batch API and slow generation jobs), but the skeleton transfers to any system that receives external event notifications.

Reframe dropped events as the normal case, not an anomaly

Webhooks promise at-least-once delivery. That means "we will try to deliver at least once," not "exactly one delivery will always land." The sender retries a few times, but if your endpoint keeps failing, it exhausts the retry budget.

As an indie developer running this alone, this happens for real. In my environment, Cloudflare Workers redeploys run more than ten times a day. Each one opens a few-hundred-millisecond window where the receiver is shaky. Cold starts and transient 5xx pile onto that. The odds of every sender retry landing inside that window are low, but not zero. Run a few dozen operations a day and one or two will go quietly missing each month.

The point is to stop banishing this to exception handling as a "rare failure." If you adopt event-driven, dropped events are normal behavior your design must absorb. So you keep Webhooks as the primary path, and guarantee recovery through a separate reconciliation path. I treat that doubling-up as a premise from day one.

The shape: split a fast path from a slow path

The design has three parts.

PartRoleTrigger
Operation ledgerThe single source of truth for the state of every submitted operationOn job submission
Webhook receiver (fast path)Receives terminal events immediately and closes the ledger entryNotification from Gemini
Reconciliation poller (slow path)Scans for unfinished entries and recovers any dropped terminal eventPeriodic cron

The key is to manage the ledger by "did the operation reach a terminal state," not "did a webhook arrive." There are two ways to confirm a terminal state: the webhook (fast), and an operations.get-style query at reconciliation time (slow but reliable). The state transition is made idempotent so the result is identical no matter which one confirms first.

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
A complete TypeScript implementation that pairs a KV operation ledger with a Webhooks fast path and a reconciliation slow path so terminal events are never lost
The exact logic for recovering a webhook that never arrived during a deploy, plus where to put the idempotency key so side effects never fire twice
The detection threshold for operations that get stuck, and the measured trade-offs behind how often I reconcile
Secure payment via Stripe · Cancel anytime

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Gemini Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

Related Articles

API / SDK2026-07-14
When a Batch Job Sat in RUNNING for Half a Day: Field Notes on Catching Stalls Early with Per-State Dwell Budgets and Record Reconciliation
When a Gemini Batch job stalls quietly under the shadow of the 24-hour SLA, per-state dwell-time budgets and submitted-vs-completed record reconciliation let you name the stall early. Field notes with real operational numbers.
API / SDK2026-07-03
A Webhook Is a Claim, Not a Fact — Three Layers of Defense for Your Gemini Webhooks Endpoint
Your Gemini Webhooks receiver is a public URL, which means forged events, replays, and duplicate deliveries are all on the table. This walkthrough builds a three-layer defense — reachability checks, dedupe, and a lightweight handler that re-fetches truth from the API — with working FastAPI and SQLite code.
API / SDK2026-06-28
The Morning a Managed Agent Stalled and Left No Trace — Building a Run-Observability Layer Outside the Sandbox
With Gemini Managed Agents, the sandbox lives on Google's side, so when a run stalls there is nothing left in your own logging stack. This is a working TypeScript design for an outside observability layer that taps stream events into a ledger, detects silent stalls, and folds runs into readable postmortems.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →