Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Retries on connection failures and on a closed idle keep-alive connection

オープン
  • 何か問題がありますか？
#695 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python
領域
backend, networking

調査の方向性

Read docs/design/RETRY_AND_RESILIENCE_DESIGN.md first, then trace request handling in the relevant HTTP-library backends and BaseDAVClient; the issue specifically mentions _async_request() and the existing rate-limit retry loop. Compare how each backend reports a connection closed before sending versus mid-response, and check the existing tests for those paths. Done means safe retries follow the design without duplicating writes or conflicting with existing retry handling.

索引モデルが issue の本文から書いたものです。

説明

enhancement

I found quite some duplications - #620, #648 and #647 is closed now, and this issue is now used for tracking retry behaviour in general.

The brief summary is like this:

  • There are different kinds of failure modes where one or more retries would be appropriate.
  • For some failure modes (like http keepalive connection closed), the default may very well be a quick retry.
  • For most failure modes, retries should be an opt-in configurable option.

The design is written up in docs/design/RETRY_AND_RESILIENCE_DESIGN.md. It should be read before implementing anything here.

The exact mechanism of how to do retries may vary between the different http-libraries. I do believe this logic belongs in the http-library and not in the caldav library. Niquests seems to come with batteries included, and is the recommended and officially supported http-library. A "best effort" should be done to support httpx2 and the old requests as well, but we should not create special logic in the caldav library for simple http-retries. This means the current logic for handling rate-limiting errors from the server may be removed. This may be a breaking change for httpx-users.

The full text below was generated by Claude Opus.

Symptom

A full local test run against the docker test servers errored on one Stalwart test:

ERROR tests/test_async_integration.py::TestAsyncForStalwart::test_change_attendee_status_with_email_given
  - niquests.exceptions.ConnectionError: Remote end closed connection without response

It passes when re-run on its own, so it is a race rather than a broken test.

Diagnosis

The library has no connection-error handling at all:

  • no except ConnectionError anywhere under caldav/
  • no max_retries, Retry, HTTPAdapter or mount anywhere either, so the
    session runs on the HTTP library's defaults - and both requests and
    niquests default to retrying nothing

"Remote end closed connection without response" on a pooled connection means the
server closed an idle keep-alive socket and the client picked that socket for the
next request; the request was never delivered.

This is not only a test-suite problem. Any long-lived client - a daemon polling
a calendar every few minutes, a desktop client left open - will outlast some
server's keep-alive timeout and get an exception on its next call, where a
transparent retry is what every other HTTP client does.

Suggested fix

Retry once when the connection was closed before the request was sent. That
case is safe regardless of method, because nothing reached the server, so a retry
cannot duplicate a write.

Points to be careful about:

  • Distinguish "closed before the request was sent" from "closed mid-response".
    Only the first is unconditionally safe; retrying a PUT/POST/DELETE that
    may have been delivered is not.
  • requests/niquests and the httpx family surface this differently, and the
    async client can be running any of niquests, httpx2, httpxyz or httpx - so the
    retry belongs where the exception types are already known per backend, not in a
    single blanket except.
  • Cap it at one retry, and do not stack it on top of the existing rate-limit
    retry loop in BaseDAVClient.
  • There is already a connection-abort workaround for
    https://github.com/python-caldav/caldav/issues/158 in _async_request() (a
    probe GET to detect an auth challenge); whatever is added here should not
    collide with it.

Found while investigating intermittent failures in a full local test run, during
the v3.3.0 release preparation. Not a v3.3.0 blocker - the failure is a race,
and the released behaviour is no worse than 3.2.x - so filing for 3.4.0.

主要言語
Python
スター
412
フォーク
113
平均マージ
22時間 43分
マージ済み PR（30日）
43

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

python-caldav/caldav のほかの issue

python-caldav/caldav の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。