James Coholan
All writing

Field note 04 / Messaging gateway

Answering in iMessage under a 120-second request limit

Starting the assistant's turn inside the webhook cut seconds of latency, until the wait itself matched the platform's timeout. The fix: nested timeouts and exactly-once delivery.

  1. 01

    Symptom

    Assistant replies in iMessage started 2.2 to 2.7 seconds after the inbound text, and most of that was a task-queue hop.

  2. 02

    Diagnosis

    • The serverless platform only gives CPU to open requests, so work handed off after responding has to wait for the queue.
    • Starting the turn inside the webhook request removed the hop, but the first version waited up to 120 seconds, exactly the service's request timeout.
    • A slow turn could be killed by the platform instead of finishing cleanly.
  3. 03

    Fix

    • The webhook starts the turn inline and waits at most 100 seconds, clamped to 110, safely under the 120-second limit. The model bridge gives up at 85.
    • A task scheduled 15 seconds later is the safety net for any turn that outlives the request.
    • A transactional claim and idempotent send keys make sure exactly one path answers.
What I do now

Keep every wait inside the one around it

  1. Write down every timeout in the chain: client, gateway, platform, and provider.
  2. Nest them, so each inner wait ends before the outer one.
  3. Pair a fast inline path with a delayed safety net.
  4. Make the two paths race on a transactional claim, not on luck.
  5. Use idempotent send keys, so a retry never sends twice.