Inconsistent transient-error (5xx) retry across adapters #1
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Category: Reliability · Priority: HIGH
Summary
Adapters handle HTTP errors inconsistently.
hackernews.pyandhuggingface.pyretry5xxwith exponential backoff;arxiv.py,github.py, andreddit.pycatchHTTPError, print the code, and drop the batch with no retry. Same failure class, different behavior per file.Why it matters
A transient 503/500 from an upstream (common on arXiv) silently yields a zero-fetch cycle. The data is lost with no recovery attempt.
What happens if not done
Recurring gaps in the research record; trends missed because a source blipped that day. Compounds with issue #2 (no failure classification) and #3 (no degradation alerting).
Suggested approach
Add a shared retry helper in
adapters/__init__.py: exponential backoff on 429/5xx only, 2 attempts, capped wait. Route all five adapters through it.Resolved by PR #12 (commit
feba2fe). Shared retry helper inadapters/__init__.pywith exponential backoff on 429/5xx, 2 attempts, capped wait. All adapters now route through it.Resolved by PR #12 (commit
feba2fe). Shared retry helper in adapters/__init__.py with exponential backoff on 429/5xx, 2 attempts, capped wait. All adapters now route through it.