fix(swift-example-app): prevent UInt64.max overflow crash in TransferCreditsView amount parsing

[QuantumExplorer]

Issue being fixed or feature implemented

TransferCreditsView.parsedCredits had a crash-class bug identical to the one fixed in WithdrawCreditsView (#3907).

It guarded the scaled credit amount with:

let credits = (dash * Double(Self.creditsPerDash)).rounded()
guard credits >= 1, credits <= Double(UInt64.max) else { return nil }
return UInt64(credits)

Double(UInt64.max) is not exactly representable and rounds up to 2^64, so the <= guard admitted a value (2^64) one above UInt64's representable range, and UInt64(credits) then trapped. Because parsedCredits recomputes on every keystroke (before any submit-time re-validation), a user typing a DASH amount that scales to ~2^64 credits (input around 1.844e8 DASH) crashed the Transfer Credits sheet on input instead of producing a friendly disabled-button state.

What was done?

Changed the upper bound to a strict < so 2^64 is rejected and the UInt64(credits) cast stays in range, with a comment explaining why. This mirrors the exact fix applied to WithdrawCreditsView in #3907.

// Strict `<`: `Double(UInt64.max)` isn't exactly representable and
// rounds up to 2^64, so a `<=` bound would admit 2^64 and trap on
// the `UInt64(credits)` cast (this recomputes on every keystroke,
// before submit-time re-validation). `<` keeps it in range.
guard credits >= 1, credits < Double(UInt64.max) else { return nil }

How Has This Been Tested?

Built the app for the iOS simulator from packages/swift-sdk:

xcodebuild -project SwiftExampleApp/SwiftExampleApp.xcodeproj -scheme SwiftExampleApp \
  -sdk iphonesimulator -destination 'platform=iOS Simulator,id=<booted-udid>' \
  EXCLUDED_ARCHS=x86_64 build

→ BUILD SUCCEEDED.

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Fixed a validation issue in credit transfers that could cause an overflow when processing maximum credit amounts. Credit validation now more strictly enforces upper boundary limits to prevent edge case errors.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: cceba2ff-4492-48f5-93d5-a7969a99b94f

📥 Commits

Reviewing files that changed from the base of the PR and between 792fd44 and f47ca01.

📒 Files selected for processing (1)

• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/TransferCreditsView.swift

---

📝 Walkthrough

Walkthrough

In TransferCreditsView.swift, the parsedCredits computed property's upper-bound validation is tightened from <= Double(UInt64.max) to < Double(UInt64.max). Inline comments are added to explain that Double(UInt64.max) rounds up due to floating-point representation, which would cause an overflow when cast back to UInt64.

Changes

UInt64 Overflow Boundary Fix

Layer / File(s)	Summary
parsedCredits strict upper bound guard packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/TransferCreditsView.swift	Validation operator changed from <= to < for the Double(UInt64.max) upper bound check, with added comments explaining the floating-point rounding overflow risk.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Suggested reviewers

• shumkov
• llbartekll
• ZocoLini

Poem

A <= once let numbers sneak through,
A float rounded up — overflow, oh no!
🐇 Now < guards the gate with care,
UInt64 stays safe, no overflow dare.
The rabbit hops on, boundary secure! 🥕

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and specifically describes the main fix: preventing UInt64.max overflow crash in the TransferCreditsView amount parsing logic.
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.

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

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/serene-hellman-b43d90

---

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.}

[thepastaclaw]

✅ Review complete (commit f47ca01)

[thepastaclaw]

Code Review

One-line <= → < fix in TransferCreditsView.parsedCredits correctly addresses the UInt64.max overflow trap caused by Double(UInt64.max) rounding to 2^64. Change is well-commented, narrowly scoped to the SwiftExampleApp, and surrounding guards already handle NaN/infinity/negative/sub-1 cases. Both agents found no in-scope defects.