← Back to baseline

DEF-003 — Songs attempt to load on /rank without filter

Summary

On first load of /rank, the app begins fetching songs automatically with default filters (pop / all / all) even though the user has not pressed Apply. This leads to continuous background fetches before any user interaction.

Environment

• App: Melodex live
• Commit: 6a951eb
• Browser: Firefox 142.0.1 (desktop)
• Device: Windows 11 laptop
• Network:Spectrum (approx 450 up / 11 down)
• Date/Time: 09-18-2025

Preconditions

• User is authenticated with any log in options.
• Navigate to /rank directly without setting any filters.

Steps to Reproduce

1. Log into melodex.io with a valid account.
2. Go directly to /rank without selecting filters.
3. Observe network/console activity.

Expected Result

No songs should be fetched until the user explicitly chooses filters and clicks Apply.

Actual Result

• SongProvider triggers background fetch immediately on mount.
• Default filter values (pop / all / all) are applied implicitly.
• Multiple fetch loops occur, buffering ~13–15 songs each cycle.
• Occasional timeouts logged (DOMException: The operation was aborted).

Impact

• Backend is hit with unnecessary API requests, leading to wasted network calls and error logs.
• Perceived reliability is reduced due to visible timeouts in console.

Attachments

• HAR: DEF-003-network
• Screenshot/GIF: DEF-003-rank
• Console log: DEF-003-console

Triage

• Severity: Minor
• Priority: Medium

Suspected Areas

• SongProvider useEffect lifecycle hook
• Filter state initialization logic (default values applied as “selected”)
• Background fetch trigger conditions not checking for “Apply” action

Diagnostics (what we tried)

• Observed console logs: repeated Triggering background fetch for more songs entries.
• Confirmed auth context resolves mid-sequence, but fetch starts even before user context is available.
• Reproduced on multiple browsers and network conditions.

Proposed Fix (initial)

• Add guard: only trigger background fetch when user explicitly applies filters.
• Treat default state as “unset” rather than as valid filter selection.
• Add regression test to ensure no fetch occurs on initial load.

---

Owner: Michael DeReus Status: Open
Opened: 09-18-2025

Linked Items

• Risk: R-21 (Unbounded background fetch inflates API usage / cloud costs)
• Test: EXP-01 (in baseline)

---

Root Cause (fill after fix)

A combination of state transitions and insufficient guards caused generateNewSongs to re-trigger repeatedly:
- filtersApplied + isRankPageActive became true while no cooldown/in-flight check prevented subsequent calls.
- The background trigger didn’t gate on buffer/list counts, so it kept scheduling more fetches even when enough songs were already loaded.
- Initial load and background fetch logic overlapped, creating a loop after filters were applied.

Fix Reference

• Commit: 958a682
• PR: #4

Verification Steps (post-fix)

1. Open /rank, apply a filter set (e.g., Rock / any / all decades).
2. In the console, confirm:
3. “Initial fetch (post-apply)” appears once.
4. “Burst page 1/2 … buffer size now …” logs occur, then stop around ~33 items.
5. No further generateNewSongs/API calls while idle.
6. Switch pages and return to /rank: verify there’s no repeated background burst unless filters change.

Verified in: commit 958a682 / date 09-18-2025
Verification Status: Pass