How 46 tracks exposed a 340-track Spotify playlist ingestion bug.

The first result looked good enough to trust

The source was the public playlist FIFA Songs ⚽ Best FIFA songs of all time. Pasted into the live site, it produced 46 readable Spotify rows with recording identifiers. Matching those rows returned 45 confident Apple Music candidates and one missing result. There were no browser errors, the progress flow completed, and the numbers looked coherent.

That result was initially useful as a user-flow test, but it was not enough as a completeness test. The playlist was visibly a large collection, so a second environment was used before publishing the 45-of-46 total as evidence of overall matching quality. The local web app, connected to the standalone ingestion backend, returned 340 readable tracks from exactly the same public URL.

The mismatch changed the interpretation completely. The 45 matches were real matches for a partial input, but they said nothing reliable about the other 294 rows. A high percentage calculated from an incomplete source is not a successful transfer report.

Comparison method

1. Use the same normal Spotify playlist URL in both environments.
2. Run only the public preview step, before Apple Music authorization or playlist creation.
3. Record the playlist ID, reported total, returned track-array length, and ISRC count.
4. Repeat the production preview in a fresh page to rule out a stale browser state.
5. Confirm that both environments are reading the same source rather than a copied fixture.
6. Inspect the two server paths to identify where their behavior diverges.

The production result remained at 46 after a repeat. The backend result remained at 340. That stability ruled out a one-off rendering problem and moved the investigation to the server boundary. No Apple Music write permission was requested during this comparison.

Why the Worker stopped with a believable partial result

The public Spotify playlist response provides track identifiers, but PlaylistXfer also retrieves recording metadata for each identifier so the match report can use fields such as ISRC, artists, album, and duration. The Cloudflare-native implementation performed that expansion with one outgoing metadata request per track.

Edge Workers have limits around outgoing subrequests. The code also treated an individual metadata failure as a skipped row, then built the displayed total from the number of successful rows. Once requests beyond the available budget failed, the surviving 46 rows were filtered into an otherwise valid-looking playlist. The interface therefore had no explicit error to display.

The production fix: one ingestion boundary

Playlist expansion now runs through the standalone transfer backend, which is not constrained by the Worker’s per-request subrequest budget. The Worker makes one internal request and receives the normalized track list as a single response. Cloudflare still owns the native Apple Music matching jobs, review state, analytics policy, and D1 persistence.

This is a narrow architectural change rather than a return to a fully proxied application. Public song links remain local because one song needs only a small number of requests. Public playlist links use the dedicated ingestion path because their size is unbounded within the product’s supported limit.

The new boundary also rejects an empty or malformed upstream playlist instead of turning it into a successful zero-row preview. Automated tests assert that a 340-track response crosses the Worker boundary in one request and preserves all 340 rows.

Why the original 45-of-46 match report was rejected

The partial report did demonstrate two behaviors: the Apple Music search job completed, and it was willing to leave an unsafe candidate missing. It did not demonstrate a 98% success rate for the source playlist. Publishing it that way would confuse precision with coverage.

Precision asks whether the selected Apple Music candidates are correct. Coverage asks whether every source row entered the matching stage. Both are necessary. The incident occurred before write authorization, so no incomplete destination playlist was created during the audit. The full 340-row source must be analyzed separately before any new aggregate match-rate claim is published.

How to verify a large playlist before trusting the match percentage

Start with the source count shown by Spotify and compare it with the preview count. Duplicates can be intentionally removed when the same Spotify track ID appears more than once, and unavailable rows can occasionally lack readable metadata, so a small documented difference may be expected. A 294-row difference is not.

Then compare the preview total with the analysis total. The Full playlist mode should send every supported preview row into matching, up to the current 500-row web limit. Faster test modes intentionally analyze only their selected scope and label that limitation in the report.

Finally, keep reading and writing separate. Verify the source, inspect the Apple Music candidates, and only then authorize creation. If any stage reports a smaller count, stop and explain the difference before treating the final percentage as meaningful.