PageSource.fetch in Agno, which loads every page and nested index during Knowledge.sync_pages, now abandons a stalled connection after 5 seconds and retries it on a fresh one. Syncing docs.agno.com used to fail one or two random pages per run with Connection reset by peer. A hung TLS handshake ate the whole 30 second fetch deadline, so no retry could run.
| Earlier releases | This release | |
|---|---|---|
| Attempts | 3 | 5 |
| Timeout per attempt | whatever remained of the 30 s deadline | 5 s to connect; 10 s read, write and pool timeouts |
| Waits | 0.25 s, 0.5 s | about 0.5, 1, 2, 4 s, each times a random 0.5 to 1.0 |
Retry-After | ignored | honored on 429 and 5xx, capped at 10 s |
| Dropped connections | failed | retried (RemoteProtocolError, WriteError) |
The 30 second deadline still caps each fetch, and a retry that would wait past it fails right away with the transport error as its cause. On the deployment that hit the bug, the stalled handshake timed out at 5 seconds, the second attempt succeeded, and the sync finished with 0 failed pages. Class attributes on PageSource, such as fetch_attempts and attempt_timeout_seconds, tune the policy.
See the cookbook, and learn more about syncing published pages in the documentation.
Frequently asked questions
Agno page sync makes up to five attempts per fetch, waiting about 0.5, 1, 2 and 4 seconds between them, each wait multiplied by a random factor between 0.5 and 1.0.
Timeouts, connection and read errors, dropped connections such as RemoteProtocolError and WriteError, 429 responses and 5xx responses. Other 4xx responses, foreign redirects, oversized bodies and cancellation fail on the first request.
Yes. PageSource exposes class attributes for it, including fetch_attempts, retry_base_seconds, retry_max_seconds, retry_after_max_seconds, connect_timeout_seconds and attempt_timeout_seconds.


