Fix Steam collections failing to load#1726
Conversation
Two issues stopped collections from loading: - Release builds (R8) stripped the reflection-only CloudConfigStoreService constructor, so createService threw and the fetch never ran. Added a keep rule for UnifiedService subclasses. - The fetch ran once at login into the post-login PICS burst with no retry, so a starved or dropped reply left collections stuck until the next login. It now retries with backoff and bails cleanly if the account changes.
📝 WalkthroughWalkthrough
ChangesSteam collections and unified service runtime
Estimated code review effort: 3 (Moderate) | ~15 minutes Possibly related PRs
Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant SteamService
participant SteamUnifiedMessages
participant CloudConfigStore
participant SteamCollectionRepository
SteamService->>SteamUnifiedMessages: Resolve handler
SteamService->>CloudConfigStore: Request collection download
CloudConfigStore-->>SteamService: Return response or failure
SteamService->>SteamService: Retry and verify session
SteamService->>SteamCollectionRepository: Store parsed collections
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
app/src/main/java/app/gamenative/service/SteamService.kt (1)
4126-4134: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueExplicitly rethrow
CancellationException.Catching
Throwablewill also catchCancellationException, which is used by Kotlin coroutines for cancellation. Although the current logic gracefully exits (becausedelayrethrows the exception orsameSession()evaluates to false on logout), catching it logs a confusing failure message and violates general coroutine best practices.Consider adding an explicit catch block to rethrow
CancellationException, consistent with other areas in this file.♻️ Proposed refactor
- } catch (t: Throwable) { + } catch (e: CancellationException) { + throw e + } catch (t: Throwable) { val lastAttempt = attempt == maxAttempts - 1 Timber.tag("SteamCollections").w(🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/java/app/gamenative/service/SteamService.kt` around lines 4126 - 4134, Update the exception handling around the Steam collections fetch retry loop to catch and immediately rethrow CancellationException before the broad Throwable handler. Keep the existing retry, logging, and cached-snapshot behavior unchanged for non-cancellation failures.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@app/src/main/java/app/gamenative/service/SteamService.kt`:
- Around line 4126-4134: Update the exception handling around the Steam
collections fetch retry loop to catch and immediately rethrow
CancellationException before the broad Throwable handler. Keep the existing
retry, logging, and cached-snapshot behavior unchanged for non-cancellation
failures.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3449c7f1-c629-47b4-be3b-52035725e0f1
📒 Files selected for processing (2)
app/proguard-rules.proapp/src/main/java/app/gamenative/service/SteamService.kt
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
2 participants
Some users reported their Steam collections never loading (or sitting on the loading state indefinitely). Two separate causes.
1. Release builds stripped a reflection-only constructor
SteamUnifiedMessages.createServiceinstantiatesCloudConfigStoreServicereflectively. R8 can't see that call, so in minified builds it dropped the(SteamUnifiedMessages)constructor —createServicethen threwNoSuchMethodExceptionand the fetch bailed straight to the cached snapshot. Debug builds aren't minified, which is why it never showed up in testing.Fix: keep the constructor for
UnifiedServicesubclasses (the existingin.dragonbra.javasteam.**rule covers JavaSteam's own generated services, but not app-side stubs like this one).2. The fetch was one-shot with no retry
Collections are fetched once, at login, right as the whole-library PICS burst goes out. If that reply is starved or dropped, nothing recovered it until the next login — so collections stayed empty/stuck.
Fix: retry with backoff (3s / 8s / 20s, 30s per attempt) and bail cleanly if the account changes mid-flight.
#1 is release-only; #2 can bite any build under load. Verified on a release build — collections populate after login.
Summary by cubic
Fixes Steam collections getting stuck on loading by preserving reflective service constructors in release builds and adding a backoff-based retry that respects cancellation after login.
in.dragonbra.javasteam.steam.handlers.steamunifiedmessages.UnifiedServicesoSteamUnifiedMessages.createService(CloudConfigStoreService)works in minified builds.CancellationException, and drop results if the account/session changes mid-flight.Written for commit 4f38210. Summary will update on new commits.
Summary by CodeRabbit