SyncReport.failed_paths in Agno holds up to 20 paths, the same cap as errors, while failed keeps the full count. A sync of docs.agno.com kept failing one or two random pages out of 3,913, and the old log line gave no page and no cause to chase.
We forced a connection reset on one page of a three page llms.txt and ran Knowledge.sync_pages on both releases.
# Earlier releases (real output)
WARNING Page sync failed (SyncFailed)
status: partial | failed: 1
# This release (real output)
WARNING Page sync failed for /guides/setup.md (SyncFailed: sync_failed <- ConnectError: [Errno 104] Connection reset by peer)
status: partial | failed: 1 | failed_paths: ('/guides/setup.md',)The prune path logs a matching Page delete failed for … warning. Your application can show users which pages to check, or treat a run where a handful of thousands failed as a success that needs a retry. A partial run still skips pruning until a clean sync.
See the cookbook, and learn more about syncing published pages in the documentation.
Frequently asked questions
Read SyncReport.failed_paths from the report that Knowledge.sync_pages or async_sync_pages returns. It lists the site paths of up to 20 failed pages, such as /guides/setup.md, and SyncReport.failed holds the full count.
No. The field defaults to an empty tuple, so code written for earlier releases and reports stored before this release keep working.
The warning names the page and the chain of errors behind it on one line, capped at 300 characters, for example a SyncFailed caused by an httpx ConnectError. Failed deletions on the prune path log a Page delete failed warning.

