fix: Cap Steam DL size to installSize to avoid gigantic dl size reporting.

[phobos665]

Description

Cap the Steam App's DL size to installSize if it's larger than InstallSize.

This helps alleviate and issue where the DL size is incorrectly reported and showing gigantic sizes instead.

It looks like it's hard to figure out this edge-case, so it's best for now to cap it and we can investigate in more detail later.

Recording

Before:

After:

Type of Change

• Bug fix
• Performance / stability improvement
• Compatibility improvements
• Other (requires prior approval)

Checklist

• If I have access to #code-changes, I have discussed this change there and it has been green-lighted. If I do not have access, I have still provided clear context in this PR. If I skip both, I accept that this change may face delays in review, may not be reviewed at all, or may be closed.
• This change aligns with the current project scope (core functionality, stability, or performance). If not, it has been explicitly approved beforehand.
• I have attached a recording of the change.
• I have read and agree to the contribution guidelines in CONTRIBUTING.md.

---

Summary by cubic

Cap Steam download size to the install size when the reported download is invalid or larger than install size. This fixes cases where the app showed gigantic download sizes due to bad manifest data.

^{Written for commit 95d728c. Summary will update on new commits. Review in cubic}

Summary by CodeRabbit

• Bug Fixes
  • Fixed an issue where download sizes could be incorrectly calculated as larger than expected by implementing proper validation logic.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds validation to SteamUtils.getDownloadBytes() to prevent returning invalid download byte values. When manifest.download is positive and within bounds (≤ manifest.size), it is returned; otherwise, manifest.size is used as a safe fallback to avoid oversized download representations.

Changes

Download Size Validation

Layer / File(s)	Summary
Download byte validation app/src/main/java/app/gamenative/utils/SteamUtils.kt	The getDownloadBytes method adds a conditional check to cap invalid manifest.download values by returning manifest.size unless download is positive and download <= size.

Possibly related PRs

• utkarshdalal/GameNative#1405: The main PR's change to SteamUtils.getDownloadBytes(manifest) directly impacts this PR's updated Steam download weight/progress calculations that call SteamUtils.getDownloadBytes(mInfo).
• utkarshdalal/GameNative#924: Both PRs touch SteamUtils.getDownloadBytes(...), with the main PR refining the helper's download vs size selection logic while the retrieved PR introduced/uses the same helper for manifest download-byte compatibility.

Suggested reviewers

• utkarshdalal

Poem

🐰 A manifest's truth we now validate,
Download bytes checked before their fate,
No oversized claims shall slip through,
Size becomes our safe rescue,
Bounds respected, downloads true! 📊

---

🎯 2 (Simple) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The description includes all required template sections with substantive content: clear explanation of the change, before/after screenshots, bug fix type selection, and all checklist items marked complete.
Title check	✅ Passed	The title directly reflects the main change: capping Steam download size to install size, which is precisely what the code modification implements.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

app/src/main/java/app/gamenative/utils/SteamUtils.kt (1)

94-95: ⚡ Quick win

Consider validating manifest.size before using it as the fallback.

While the current fix correctly addresses the reported bug (oversized manifest.download), the fallback to manifest.size assumes that value is itself valid. If both fields are corrupted, the function could still return an invalid size.

🛡️ Proposed additional validation

     // Cap DownloadSize to installSize due to incorrectly gigantic sizes
-    // DL size should always be smaller than installSize.
+    // DL size should not be larger than installSize.
     val hasSaneDownload = manifest.download > 0L && manifest.download <= manifest.size
-    return if (hasSaneDownload) manifest.download else manifest.size
+    val hasSaneSize = manifest.size > 0L
+    return when {
+        hasSaneDownload -> manifest.download
+        hasSaneSize -> manifest.size
+        else -> 0L
+    }
 }

Note: The downstream caller already applies .coerceAtLeast(1L), so returning 0L for completely invalid data would be safely handled.

🤖 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/utils/SteamUtils.kt` around lines 94 - 95,
The current logic uses manifest.size as an unconditional fallback when
manifest.download is invalid (hasSaneDownload), but manifest.size may also be
corrupted; add a second validation (e.g., hasSaneSize) that ensures
manifest.size > 0 and >= manifest.download lower bound before returning it, and
if both are invalid return 0L (the caller will coerce to at least 1L). Update
the code that currently defines hasSaneDownload and the subsequent return to
check manifest.size as well (referencing manifest.download, manifest.size and
hasSaneDownload) and return 0L when neither value is valid.

🤖 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/utils/SteamUtils.kt`:
- Around line 94-95: The current logic uses manifest.size as an unconditional
fallback when manifest.download is invalid (hasSaneDownload), but manifest.size
may also be corrupted; add a second validation (e.g., hasSaneSize) that ensures
manifest.size > 0 and >= manifest.download lower bound before returning it, and
if both are invalid return 0L (the caller will coerce to at least 1L). Update
the code that currently defines hasSaneDownload and the subsequent return to
check manifest.size as well (referencing manifest.download, manifest.size and
hasSaneDownload) and return 0L when neither value is valid.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a522d926-5f73-47e0-88e8-fbd04731589f

📥 Commits

Reviewing files that changed from the base of the PR and between 30e8205 and 95d728c.

📒 Files selected for processing (1)

• app/src/main/java/app/gamenative/utils/SteamUtils.kt

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}