Follow-up to #491, which was fixed in 4.8.5 by making mid-download
resume opt-in (safe default: fail and delete the staged file, since
switching networks can route a stable URL to a different CDN object).
That fix only changes what happens on a *real* read error. It doesn't
help if a transport surfaces a mid-transfer connection drop as a plain
io.EOF instead of io.ErrUnexpectedEOF - fileDownload's copyBody loop
still breaks out and promotes the file on any clean EOF, regardless of
whether written bytes actually reached Content-Length. This app's
uTLS-based client (used for TLS-fingerprint spoofing) is exactly the
kind of custom transport where that guarantee isn't necessarily upheld.
Now a clean EOF short of a known Content-Length is routed through the
same resume-or-fail path as a real read error, so it respects the same
opt-in `resume` option: fails and cleans up the staged file by default,
or resumes via Range/If-Range when the caller explicitly requested it
and the server provided a validator.
extension_runtime_file_download_integrity_test.go adds three tests:
- fails by default even when a validator is present (matches the
opt-in policy from 4.8.5)
- resumes correctly when `resume: true` is passed
- fails and cleans up when there's no validator at all
All three fail on the pre-fix code and pass with it.
Note: fileDownloadChunked's unknown-total-size path (used for
YouTube's CDN) has an analogous but harder-to-fix ambiguity - without
a known length there's no way to distinguish a legitimately short
final chunk from a truncated one - left as a follow-up.
Fixes#368.
Reopening a Spotify playlist from "recent access" showed no tracks,
while the first view (right after pasting the URL) worked fine.
Root cause traced across two layers:
1. Go: ExtURLHandleResult (the parsed shape of an extension's handleUrl()
return value) never captured a top-level `id` for the handled
resource. Track/album/artist results carry their own id inside their
nested metadata, but a plain playlist result has no such object, so
its id was silently dropped everywhere from the goja parser through
to the JSON the Dart side receives.
2. Dart: TrackState had nowhere to put that id even if it existed
(only playlistName), so recording a "recent" playlist access stored
the playlist's *name* as if it were its id. Reopening it later fed
that name into PlaylistScreen's provider-guessing logic
(legacyProviderIdFromResourceId, which only recognizes legacy
"provider:id" prefixes), which naturally failed and fell through to
a hardcoded Deezer metadata fetch using a Spotify playlist's name as
the resource id - guaranteed to return nothing.
Fix, matching the "generic API, not per-provider checks" architecture
in CONTRIBUTING.md:
- go_backend/extension_provider_wrapper.go: add ExtURLHandleResult.ID.
- go_backend/extension_goja_convert.go: parse it from the handler's
return value.
- go_backend/exports_extensions.go: surface it in the JSON response.
- lib/providers/track_provider.dart: add TrackState.playlistId,
populated from the response's `id` field for playlist results.
- lib/screens/home_tab.dart: record the real playlist id (falling back
to the name only if a provider never supplies one) and pass both the
id and the already-known provider id forward to PlaylistScreen.
- lib/screens/playlist_screen.dart: PlaylistScreen gains a
metadataProviderId param that takes priority over guessing from the
id's shape.
- lib/screens/home_tab_recent.dart: pass the recent-access entry's
stored providerId through when reopening a playlist.
- lib/utils/provider_resource_ids.dart: extract the
known-id-vs-guessed-id preference into a small, directly testable
resolvePreferredMetadataProviderId helper.
Note: this fixes the common case (an extension already reported its
own id as the source provider for the URL it handled). If a provider
never supplies an id for its handleUrl() playlist result, playlistId
stays null and behavior is unchanged from before this fix - no
regression, just not a complete fix for that narrower case, since
that would require changes in extension-side JS code outside this
repo.
Tests:
- go_backend/extension_goja_convert_url_handle_test.go: the new ID
field round-trips from a handler's return value, and stays empty
when the handler doesn't supply one.
- test/provider_resource_ids_test.dart: resolvePreferredMetadataProviderId
prefers a known provider id, falls back to the legacy-prefix guess,
treats a blank known id as unknown, and returns null for the
unprefixed-id-with-no-known-provider case from #368 itself.
Verification: go build/vet/test and flutter analyze/test all green.
MatchesURL treated patterns as substrings of the whole URL, so
"spotify.com" matched any URL embedding it in a query parameter and a
hostile query string could route a link to the wrong handler. Patterns
now anchor to the URL host (exact domain or subdomain, optional path
prefix); "scheme:" patterns anchor to the URI front. With several
matching handlers, FindURLHandler now breaks the tie via the user's
metadata provider priority instead of Go's random map order.
Both manifest gates were parsed but only checked by the Store UI, so
manual .sflx installs and directory loads of incompatible extensions
failed cryptically at runtime despite SIGNED_SESSION_GUIDE promising a
clear refusal. validateExtensionLoad now rejects them on every install
path, and ensureRuntimeReady re-checks so a gated package cannot be
enabled anyway. Unknown runtime features and too-new feature contract
versions fail with explicit messages; an empty app version (tests)
skips the version gate.
The download-time ISRC index now also parses mp3, m4a, ogg, and opus
tags through the existing native readers instead of skipping everything
but .flac. Library settings gain a Review duplicates sheet that groups
history and local-library rows sharing an ISRC via SQL over the
attached databases (no filesystem walk, SAF-safe), shows quality
badges, and offers keep-best and per-copy delete with confirmation.
Track options gain an Open on... entry listing every streaming platform
song.link resolves for the track, served by a new generic
GetTrackPlatformLinks with its own memory cache beside the availability
cache (same request budget). The sheet is data-driven from the platform
map so the app core stays service-agnostic. Completes the bridge
wrappers already landed in 901fa34d; also carries the en strings for
the duplicate review sheet landing next.
zarzet