python: retry connection resets on idempotent GET requests - #6814
Conversation
A connection reset mid-poll (e.g. status polling during compilation) was raised immediately as FelderaCommunicationError with no retry, turning a transient network blip into a hard client failure. GET is idempotent, so retry ConnectionError there; leave POST/PUT/PATCH/DELETE unretried since a lost response may hide an already-applied write. Signed-off-by: Ben Pfaff <blp@feldera.com>
mythical-fred
left a comment
There was a problem hiding this comment.
Retry ConnectionError only for GET (idempotent) via a new is_idempotent = http_method is requests.get gate threaded into _is_retryable. POST/PUT/PATCH/DELETE keep the old behaviour — a lost response there may hide an already-applied write, so resubmitting is unsafe. Correct call: mid-poll connection resets during compilation status polls should not turn into hard FelderaCommunicationErrors. Tests cover all three paths (GET-retry-then-success, GET-retry-exhaust-then-wrapped, POST-no-retry). No new deps, tight diff (+42/-7).
The identity check http_method is requests.get is deliberate and fine given the SDK only exposes get/post/put/patch/delete helpers, but if HEAD/OPTIONS ever get plumbed through, extend the set (or key off http_method.__name__ against {"get","head","options"}).
A connection reset mid-poll (e.g. status polling during compilation) was raised immediately as FelderaCommunicationError with no retry, turning a transient network blip into a hard client failure. GET is idempotent, so retry ConnectionError there; leave POST/PUT/PATCH/DELETE unretried since a lost response may hide an already-applied write.
Describe Manual Test Plan
Ran unit tests.