Download series fails silently when the server rejects the batch

[rangoDJ]

Goal

When Download series fails, the app should say why instead of silently doing nothing.

Steps

1. On a server with the default per-user concurrent download limit (3), open a series with more than 3 episodes.
2. Tap Download series.

Expected

Either the episodes download, or the app shows the server's reason, for example that the download limit was reached.

Actual

Nothing happens and no message appears. The Downloads tab stays empty. It was first noticed on LTE, but it happens on Wi-Fi too and has nothing to do with Downloads only over Wi-Fi.

Scope

Android phone. Play Store build 1.0.0 (versionCode 220000038), Pixel 10 Pro XL.

Technical notes

Cause (confirmed). The server rejects the batch: POST /api/v2/downloads (createDownloads) returns 429 rate_limited on every Download series attempt, because the concurrent limit is checked against the episode count. That's filed as Silo-Server/silo-server#1703, which has the server logs.

The Android part: the failure is silent. DownloadEnqueuer.startSeries returns ApiResult.Error and only calls Log.w (DownloadEnqueuer.kt). ItemDetailViewModel.onSeriesDownloadTapped drops the result (ItemDetailViewModel.kt:337-345), and release builds don't write these logs, so users and support see nothing. The server's 429 problem carries a readable message ("concurrent download limit reached") that the app could show.

How it was checked on the device (release build): after tapping Download series, adb shell dumpsys jobscheduler org.siloserver.silo showed no DownloadWorker jobs, Silo had no notifications, the Downloads tab was empty, and the server logged the 429s above.

Secondary finding, not the cause here: the Wi-Fi-only preference can fall back to its default. finalizeAndEnqueue reads downloadsWifiOnlyFlow.first() (DownloadEnqueuer.kt:423). The flow comes from profileScopedFlow(true), which returns flowOf(default), meaning Wi-Fi only, when no profile is active (AndroidPlayerSettingsStore.kt:218-229). A download queued in the background with no active profile, for example by DownloadSubscriptionWorker's periodic evaluation, could get NetworkType.UNMETERED even with the setting off, and then wait for Wi-Fi. The subscription's stored wifiOnly isn't read on that path either. This is from source review only and wasn't observed on the device.

Suggested fixes

• Surface startSeries failures, and the other batch paths, to the user, including the server's problem message for 429.
• Read the Wi-Fi-only preference for the scope the worker resolved, or from the subscription, instead of falling back to the default when no profile is active.

Related: Silo-Server/silo-server#1703 (server cause), #20, #22, #329.

AI disclosure

• Harness: Claude Code (Claude desktop app, Code tab)
• Tool(s): Claude Code, GitHub CLI, adb (read-only device checks), Dockhand (read-only server logs)
• Model(s): claude-opus-5-5
• Involvement: AI-assisted. The reporter reproduced it on their phone and server. The server logs and device job state were read with the reporter present, and the code analysis is from source review at eb1e2ed.
• Adversarial review: n/a

[rangoDJ]

Correction: I posted this comment too early, so it doesn't confirm the cause. The installed app is the Play Store release, and it doesn't write the DownloadWorker log lines (enqueue id=… wifiOnly=…), so adb logcat -s DownloadWorker shows nothing on that build. The diagnosis above is still source analysis and isn't confirmed on a device.

The check that works on a release build is Android's job scheduler. While the phone is off unmetered Wi-Fi (on LTE, or on a Wi-Fi network marked metered), run adb shell dumpsys jobscheduler org.siloserver.silo. A stuck download that was queued Wi-Fi only shows up as a DownloadWorker job with CONNECTIVITY in its unsatisfied constraints.

AI disclosure: comment drafted with Claude Code (claude-opus-5-5).

[rangoDJ]

Update: I found the cause and rewrote the issue above. Download series didn't fail because of the Wi-Fi setting: the server rejects the batch with 429 rate_limited whenever the series has more episodes than the per-user concurrent download limit (default 3). That's filed as Silo-Server/silo-server#1703. This issue now covers the Android side: the failure is silent. The Wi-Fi-only default fallback is kept as a secondary, unobserved finding.

AI disclosure: comment drafted with Claude Code (claude-opus-5-5).