Web API play with bare "uris" (no context_uri) fails with unsupported context type: "" since v0.8.0 #410

Summary

Since v0.8.0, a Spotify Web API play request that names tracks directly ("uris": [...], no context_uri) is rejected by the daemon with unsupported context type: "". The Web API returns 204, nothing plays. v0.7.4 plays the same request. This is how third-party clients play Liked Songs, search results, or any ad-hoc list of tracks on a Connect device.

Environment

• go-librespot v0.10.2 (release tarball, go-librespot_linux_x86_64), Linux x86_64
• credentials.type: interactive (stored credentials), audio_backend: pipe, zeroconf_enabled: false, log_level: debug
• Reproduced on a fresh device id with no prior state; the gate is still present on master (spclient/context_resolver.go:64-67)

Steps to reproduce

1. Start go-librespot, wait for authenticated Login5.
2. From any Web API client with a user token:

   PUT https://api.spotify.com/v1/me/player/play?device_id=<go-librespot device_id>
   {"uris":["spotify:track:1BdI8NEvZx61tnkbuAxC5x","spotify:track:4u615SPuJfGtPaEUSKwuK4"]}
   

   The API answers 204.
3. Daemon log:

   level=debug msg="handling play player command from webapi-39bc398b499046dab918247f759d3292"
   level=debug msg="sending successful reply for dealer request"
   level=warning msg="failed resolve " error="failed creating track list: failed initializing context resolver: unsupported context type: "
   level=warning msg="failed loading context for play command" error="failed creating track list: failed initializing context resolver: unsupported context type: "
   level=debug msg="put connect state because PLAYER_STATE_CHANGED"
   

   /status stays stopped: true.

A single-element "uris": ["spotify:track:1BdI8NEvZx61tnkbuAxC5x"] fails identically.

Control on the same device, same session: {"context_uri":"spotify:album:3KIlhMEiSYNn8VD7e6yglU"} loads and plays normally (loading track ... uri="spotify:track:61mWefnWQOLf90gepjOCb3").

Cause

1d150cc (feat: identify unsupported URIs early) made InferSpotifyIdTypeFromContextUri return SpotifyIdTypeUnknown for anything unrecognised, and added to NewContextResolver:

typ := librespot.InferSpotifyIdTypeFromContextUri(spotCtx.Uri)
if typ == librespot.SpotifyIdTypeUnknown {
    return nil, fmt.Errorf("unsupported context type: %s", spotCtx.Uri)
}

For a uris play Spotify sends a context with an empty uri and the tracks inline in pages[0].tracks, so the resolver returns before hasResolvablePages gets a look. Before that commit the empty URI fell through to SpotifyIdTypeTrack and the inline page was used as-is.

Suggested fix

Treat an empty context URI whose pages already carry tracks as a track list, e.g. only fail on SpotifyIdTypeUnknown when spotCtx.Uri != "" (or when !hasResolvablePages(spotCtx)), defaulting typ to SpotifyIdTypeTrack otherwise. Happy to open a PR along those lines if that is the direction you prefer.

Filed by Claude (an AI assistant) on behalf of @yousefamar, who hit this through a Web API remote that plays Liked Songs as a uris list. Repro logs and analysis are from an isolated v0.10.2 instance.