[PR #422] [MERGED] Update tracks_features data model to more accurately reflect API response #444

New issue

Closed

opened 2026-02-27 20:24:45 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:24:45 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/ramsayleung/rspotify/pull/422
Author: @caass
Created: 5/31/2023
Status: ✅ Merged
Merged: 5/31/2023
Merged by: @ramsayleung

Base: master ← Head: master

📝 Commits (4)

b275dfd Update tracks_features data model to more accurately reflect API response
872ca76 Add test for known featureless track
f46b546 Update changelog
779d4cc Note breaking change

📊 Changes

4 files changed (+9 additions, -3 deletions)

View changed files

📝 CHANGELOG.md (+2 -0)
📝 rspotify-model/src/audio.rs (+1 -1)
📝 src/clients/base.rs (+4 -2)
📝 tests/test_with_credential.rs (+2 -0)

📄 Description

Description

When querying tracks_features, the Spotify API will sometimes return null instead of AudioFeatures for a track, resulting in a deserialization error. This PR updates the internal AudioFeaturesPayload type to be a Vec<Option<AudioFeature>> rather than a Vec<AudioFeature> to avoid breaking on deserialization.

Motivation and Context

When getting audio features for several thousand tracks, I could consistently get rspotify to choke on a null result for one of the IDs (6z99LwRS28wga9xc2u09Po). Here's the response I get:

{
  "audio_features": [
    {
      "danceability": 0.481,
      "energy": 0.0683,
      "key": 9,
      "loudness": -21.035,
      "mode": 0,
      "speechiness": 0.529,
      "acousticness": 0.903,
      "instrumentalness": 0.599,
      "liveness": 0.256,
      "valence": 0.519,
      "tempo": 81.948,
      "type": "audio_features",
      "id": "6Gx1aZp23xQStq1kAqexA1",
      "uri": "spotify:track:6Gx1aZp23xQStq1kAqexA1",
      "track_href": "https://api.spotify.com/v1/tracks/6Gx1aZp23xQStq1kAqexA1",
      "analysis_url": "https://api.spotify.com/v1/audio-analysis/6Gx1aZp23xQStq1kAqexA1",
      "duration_ms": 161971,
      "time_signature": 4
    },
    null,
    {
      "danceability": 0.603,
      "energy": 0.629,
      "key": 7,
      "loudness": -5.789,
      "mode": 0,
      "speechiness": 0.125,
      "acousticness": 0.707,
      "instrumentalness": 0,
      "liveness": 0.181,
      "valence": 0.389,
      "tempo": 82.078,
      "type": "audio_features",
      "id": "2pRU7Hr7vmSWT90NNOQiTd",
      "uri": "spotify:track:2pRU7Hr7vmSWT90NNOQiTd",
      "track_href": "https://api.spotify.com/v1/tracks/2pRU7Hr7vmSWT90NNOQiTd",
      "analysis_url": "https://api.spotify.com/v1/audio-analysis/2pRU7Hr7vmSWT90NNOQiTd",
      "duration_ms": 140000,
      "time_signature": 4
    }
  ]
}

I figured it'd be best to avoid breaking the tracks_features API by changing the return type from Option<Vec<AudioFeature>> to Option<Vec<Option<AudioFeature>>>, so there's now a flattening step in between receiving the API response and returning the list of audio features. This means that you won't be able to 1:1 map a result from tracks_features to the input tracks, but I don't think that was guaranteed anyway.

Dependencies

None.

Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update

How has this been tested?

I added "spotify:track:6z99LwRS28wga9xc2u09Po" as a test case to test_audios_features, which is a spotify track (https://open.spotify.com/track/6z99LwRS28wga9xc2u09Po) that returns null when querying for audio features.

Is this change properly documented?

I stuck it in the changelog, but I don't think there needs to be any doc updates.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/ramsayleung/rspotify/pull/422 **Author:** [@caass](https://github.com/caass) **Created:** 5/31/2023 **Status:** ✅ Merged **Merged:** 5/31/2023 **Merged by:** [@ramsayleung](https://github.com/ramsayleung) **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (4) - [`b275dfd`](https://github.com/ramsayleung/rspotify/commit/b275dfd33283225a672c5a4e6955d3fb08c3d19c) Update tracks_features data model to more accurately reflect API response - [`872ca76`](https://github.com/ramsayleung/rspotify/commit/872ca76cb9d4e6104a67144c058c7ae9d0d7899a) Add test for known featureless track - [`f46b546`](https://github.com/ramsayleung/rspotify/commit/f46b546760b71d870da55edabd971d5a76e7760b) Update changelog - [`779d4cc`](https://github.com/ramsayleung/rspotify/commit/779d4cc5dfdc77bd77921aaf3ce94108bf60bdb0) Note breaking change ### 📊 Changes **4 files changed** (+9 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `CHANGELOG.md` (+2 -0) 📝 `rspotify-model/src/audio.rs` (+1 -1) 📝 `src/clients/base.rs` (+4 -2) 📝 `tests/test_with_credential.rs` (+2 -0) </details> ### 📄 Description ## Description When querying `tracks_features`, the Spotify API will sometimes return `null` instead of `AudioFeatures` for a track, resulting in a deserialization error. This PR updates the internal `AudioFeaturesPayload` type to be a `Vec<Option<AudioFeature>>` rather than a `Vec<AudioFeature>` to avoid breaking on deserialization. ## Motivation and Context When getting audio features for several thousand tracks, I could consistently get rspotify to choke on a `null` result for one of the IDs (`6z99LwRS28wga9xc2u09Po`). Here's the response I get: ```json { "audio_features": [ { "danceability": 0.481, "energy": 0.0683, "key": 9, "loudness": -21.035, "mode": 0, "speechiness": 0.529, "acousticness": 0.903, "instrumentalness": 0.599, "liveness": 0.256, "valence": 0.519, "tempo": 81.948, "type": "audio_features", "id": "6Gx1aZp23xQStq1kAqexA1", "uri": "spotify:track:6Gx1aZp23xQStq1kAqexA1", "track_href": "https://api.spotify.com/v1/tracks/6Gx1aZp23xQStq1kAqexA1", "analysis_url": "https://api.spotify.com/v1/audio-analysis/6Gx1aZp23xQStq1kAqexA1", "duration_ms": 161971, "time_signature": 4 }, null, { "danceability": 0.603, "energy": 0.629, "key": 7, "loudness": -5.789, "mode": 0, "speechiness": 0.125, "acousticness": 0.707, "instrumentalness": 0, "liveness": 0.181, "valence": 0.389, "tempo": 82.078, "type": "audio_features", "id": "2pRU7Hr7vmSWT90NNOQiTd", "uri": "spotify:track:2pRU7Hr7vmSWT90NNOQiTd", "track_href": "https://api.spotify.com/v1/tracks/2pRU7Hr7vmSWT90NNOQiTd", "analysis_url": "https://api.spotify.com/v1/audio-analysis/2pRU7Hr7vmSWT90NNOQiTd", "duration_ms": 140000, "time_signature": 4 } ] } ``` I figured it'd be best to avoid breaking the `tracks_features` API by changing the return type from `Option<Vec<AudioFeature>>` to `Option<Vec<Option<AudioFeature>>>`, so there's now a flattening step in between receiving the API response and returning the list of audio features. This means that you won't be able to 1:1 map a result from `tracks_features` to the input tracks, but I don't think that was guaranteed anyway. ## Dependencies None. ## Type of change Please delete options that are not relevant. - [x] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ## How has this been tested? I added "spotify:track:6z99LwRS28wga9xc2u09Po" as a test case to `test_audios_features`, which is a spotify track (https://open.spotify.com/track/6z99LwRS28wga9xc2u09Po) that returns `null` when querying for audio features. ## Is this change properly documented? I stuck it in the changelog, but I don't think there needs to be any doc updates. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>