Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#695 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
38/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
backend, networking

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
412
Fork
113
Merge trung bình
9 giờ 52 phút
Pull request đã merge (30 ngày)
64

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của python-caldav/caldav

Tất cả issue của python-caldav/caldav

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.