Files
music_library/backlog/archive/tasks/ml-26 - No-retry-backoff-strategy-for-non-Last.fm-APIs.md
T
2026-04-20 10:02:25 +01:00

50 lines
1.8 KiB
Markdown

---
id: ML-26
title: No retry/backoff strategy for non-Last.fm APIs
status: To Do
assignee: []
created_date: '2026-04-20 08:51'
labels: []
dependencies: []
references:
- 'https://github.com/cloud8421/music_library/issues/153'
priority: medium
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
_GitHub: created 2026-04-05 · updated 2026-04-09 · closed 2026-04-08 · not planned_
## Summary
Only the Last.fm integration has structured error responses with retry classification (`{:snooze, seconds}`). All other API integrations (MusicBrainz, Discogs, Wikipedia, Brave Search, OpenAI) use simple `max_attempts: 3` with no backoff, causing immediate retries that can trigger upstream rate limits.
## Why This Matters
- Immediate retries on transient failures can cause thundering herd effects
- Rate limit errors are treated identically to other transient errors
- No exponential backoff means the same failure is likely to repeat
## Evidence
- `lib/last_fm/api/error_response.ex` — comprehensive error classification (70 lines)
- All other API modules return raw bodies on error with no classification
- `lib/music_library/worker/refresh_scrobbles.ex` (lines 26-32) — only worker with `{:snooze, seconds}`
## Suggested Fix
1. Add structured error response modules for MusicBrainz, Discogs, and Wikipedia
2. Implement backoff strategies in their respective workers
3. Classify rate-limit responses separately from transient errors
## Acceptance Criteria
<!-- AC:BEGIN -->
- API-specific workers handle rate-limit responses with appropriate snooze durations
- Transient errors use exponential backoff rather than immediate retry
<!-- SECTION:DESCRIPTION:END -->
- [ ] #1 API-specific workers handle rate-limit responses with appropriate snooze durations
- [ ] #2 Transient errors use exponential backoff rather than immediate retry
<!-- AC:END -->