Book_Appointment tool calls fired in a single LLM turn after streaming timeout — resulted in multiple appointments booked for one requested slot

Support Help
1

Problem statement: During call call_024282eaff4c300c039044b7558 (agent agent_2d8a4d22ab7c526d11a0242831, version 34), the caller requested and confirmed a single appointment slot. Immediately following a logged streaming error (“2500ms timeout reached for first token”), the response engine emitted 5 identical Book_Appointment tool calls in the same turn (same patient, same date/time, same operatory — distinct tool_call_ids), 4 of which succeeded and created duplicate appointment records for a slot the caller never asked to be booked multiple times. The agent’s normal fallback-to-next-slot logic then compounded this, leaving the patient with 7 appointment records across 3 different times instead of the single confirmed booking. @support10 @support9 @Shah-Fazal can you help?

2

what does your function look like? Also in your prompt, how are you calling that function?

3

am using mcp it’s a single prompt agent am just instructing it to invoke the tool

4

can you post your prompt?

5

how will it help here

6

@duncan Checking with the team

7

Hey @duncan What happened

  1. Available_time_slots was called with a full-month window (07/07 → 08/07), which returned a very large payload — big enough that it was truncated and pushed the model’s context to ~20k tokens.
  2. On the next turn, the model emitted 5 identical Book_Appointment tool calls in a single response — same patient, same slot (07/13 09:45), distinct call IDs, all within the same millisecond.
  3. All 5 reached your booking endpoint concurrently and all 5 committed (AptNum 126403–126407), because the “Already Booked” check evaluated before any of them had written.
  4. The agent then followed its normal “offer the next slot” behavior, booking 09:30 (126408) and 10:15 (126409).

Net result: 7 records across 3 times — 5× 09:45, 1× 09:30, 1× 10:15.

Two contributing factors

  • On our side: we did not de-duplicate identical booking calls that the model emitted in parallel within one turn — we executed all 5.
  • On your side: the “Already Booked” guard caught the sequential retries (the later 09:30 and 10:15 attempts correctly returned “Already Booked”), but not the 5 concurrent ones — they all passed the check before any committed.

Recommended fixes on your side if possible:

  1. Make Book_Appointment concurrency-safe — a unique constraint or short-lived lock on PatientId + AppointmentStartDate + OPId, rather than a read-then-write check. This deterministically closes the concurrent-duplicate case, which is the one that created the extra records here. This is the highest-impact fix.
  2. Narrow Available_time_slots — return a shorter window (e.g. 7 days) or the first N slots. The oversized response is what inflated the context and set off the whole chain, so this addresses the root trigger.
  3. add a prompt instruction like “invoke Book_Appointment at most once per confirmed slot.”

On our end

  1. We’re prioritizing a change so that identical, side-effecting tool calls emitted in parallel within a single turn are coalesced and executed once — so this class of duplicate can’t originate from our side even when the model repeats a call.
  2. We’re also improving how we handle oversized tool responses.

Thank You