GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Don't retry call-placing requests after an ambiguous failure by zorionarrillaga · Pull Request #32 · VapiAI/server-sdk-python

Conversation

@zorionarrillaga

@zorionarrillaga zorionarrillaga commented Oct 22, 2026

Copy link
Copy Markdown

Proof of concept for #31. The SDK is generated, so this shows the change and its tests for carrying over to the generator.

What broke

HttpClient.request (src/vapi/core/http_client.py) retries every request up to 2 times by default:

  • on any 5xx, 408 or 409 (_should_retry);
  • on httpx.RemoteProtocolError, a connection dropped before the reply arrived.

calls.create() is POST /call, and campaigns.campaign_controller_create()/_v_2() are POST /campaign and POST /v2/campaign. All three place outbound phone calls. A 5xx or a dropped connection can come after Vapi has already dialled: a gateway timeout, or a proxy losing the reply. The API takes no idempotency key, so it can't tell the retry from a new request. The customer's phone rings a second time, the org pays for two calls, and the caller only gets back the second call id.

How it was reproduced

I used a local mock of POST /call on 127.0.0.1 only; no Vapi account or real API was involved. The mock records every POST as a dialled call and answers the first one with 502 Bad Gateway. One client.calls.create(assistant_id=..., phone_number_id=..., customer={"number": "+14155550199"}):

PyPI 3.0.0 current main (01ebf69) this branch
calls dialled by the mock 2 (call-1, call-2) 2 (call-1, call-2) 1 (call-1)
caller sees success, call-2 success, call-2 ApiError 502

The PyPI 3.0.0 wheel's vapi/ package is byte-identical to main (diff -r is empty).

What changed

  • core/http_client.py: a new helper, _places_calls(method, path). It is true for POST to call, campaign or v2/campaign. For those requests, in both the sync and the async client:
    • a status retry happens only on 429 (rate limited, so the call was never placed);
    • a connection-error retry happens only on httpx.ConnectError (the request was never sent). RemoteProtocolError is raised to the caller instead.
  • Unchanged: every other request, including other POSTs such as assistants.create, keeps its current retries.
  • tests/custom/test_call_placing_retries.py (new, 26 cases). It uses an in-memory httpx.MockTransport through the real Vapi/AsyncVapi clients:
    • calls.create, campaign create and campaign create v2 each hit the server exactly once after 500/502/503/504/408/409 (18 cases) and after a dropped connection (3);
    • calls.create is still retried on 429, and when the connection never opened;
    • calls.list() (GET) and assistants.create() (another POST) are still retried on 503;
    • the async calls.create is sent once after a 502, and once after a dropped connection.
  • .fernignore: lists the new test, as for their other custom tests.

How it was tested

  • New tests: 23 of 26 fail on current main (every "sent once" case). The 3 "still retried" cases pass on both. All 26 pass on the branch.
  • Full suite (pytest -n 4 tests, Python 3.11.14): 105 passed, 4 skipped on the branch. HEAD gives 79 passed, 4 skipped.
  • mypy . (1.13.0, their pin): Success: no issues found in 2512 source files.
  • ruff check and ruff format --check (0.11.5, their pin): clean on both changed files.
  • Real-socket mock repro: 2 dials before the change, 1 after (table above).
  • Not run: the aiohttp-extra test job, and the Python 3.10/3.12-3.14 and pydantic v1 matrix. I ran Python 3.11 with pydantic 2 only.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@zorionarrillaga
fix: don't retry call-placing POSTs after an ambiguous failure
2a62109
POST /call, /campaign and /v2/campaign take no idempotency key, so the
default retry on 5xx, 408, 409 or a dropped connection could dial the
same customer twice. These requests are now retried only on 429 and on
connection errors raised before the request was sent. Other requests
keep their retries.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

1 participant

@zorionarrillaga
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.