fix: improve decimal handling for enhanced accuracy in order processing

[sundayonah]

Description

Describe the purpose of this PR along with any background information and the impacts of the proposed change. For the benefit of the community, please do not assume prior context.

Provide details that support your chosen implementation, including: breaking changes, alternatives considered, changes to the API, contracts etc.

References

Include any links supporting this change such as a:

• GitHub Issue/PR number addressed or fixed e.g closes Save previous provider rates in priority queue to reduce order failures #407
• StackOverflow post
• Support forum thread
• Related pull requests/issues from other repos

If there are no references, simply delete this section.

Testing

Describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this project has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

Please include any manual steps for testing end-to-end or functionality not covered by unit/integration tests.

Also include details of the environment this PR was developed in (language/platform/browser version).

• This change adds test coverage for new/changed/fixed functionality

Checklist

• I have added documentation and tests for new/changed functionality in this PR
• All active GitHub checks for tests, formatting, and security are passing
• The correct base branch is being used, if not main

By submitting a PR, I agree to Paycrest's Contributor Code of Conduct and Contribution Guide.

Summary by CodeRabbit

• Bug Fixes

  • Improved token decimal handling and more robust event parsing to reduce parsing errors and edge-case issues.

• Chores

  • Added additional internal logging to aid monitoring and debugging.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Added temporary debug/info logging in Starknet order creation and client build flows; refined a token decimals parameter type and adjusted downstream casts in Voyager event/transfer transformation code.

Changes

Cohort / File(s)	Summary
Starknet order logging services/order/starknet.go	Inserted a temporary debug/error-level log block in CreateOrder that emits ephemeral values (AccountsWallet, saltDecrypted, SaltUsed, SeedUsed, Order Account, Amount, Rate). No other logic changes.
Starknet client logging services/starknet/client.go	Added INFO-level logging in BuildApprovalAndCreateOrderCall to log orderAmountLow and orderAmountHigh before constructing the Paymaster BuildTransactionRequest.
Voyager parsing / type refinement services/voyager.go	Changed tokenDecimals type from int to float64 in TransformVoyagerTransferToRPCFormat; preserved tokenDecimals <= 0 check and cast to int8(tokenDecimals) for decimal calculations. Refactored event parsing loops/type assertions for consistency without changing observable behavior.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Review services/voyager.go casts: ensure float64→int8 casting is safe and intent-preserving for all token decimal values.
• Verify the temporary log block in services/order/starknet.go is tracked for removal and does not expose sensitive data.
• Confirm logging levels are appropriate and do not alter control flow.

Suggested reviewers

• chibie
• 5ran6

Poem

🐰 I hopped through logs at break of day,
Counting decimals that danced away,
A debug nibble, a quiet cheer,
Orders whisper secrets I hold dear,
Hoppity-hop—code clearer here! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (3 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is entirely boilerplate template text with no actual content filled in. All description sections remain as placeholder prompts with no details about the changes, purpose, testing, or implementation.	Complete the Description section with purpose/impacts, fill References with related issues, detail Testing approach with test coverage status, and verify Checklist items are addressed.
Linked Issues check	⚠️ Warning	The PR changes (logging, decimal type casting) do not address issue #407's core requirements: saving previous provider rates to Redis with '_prev' suffix and updating AssignLockPaymentOrder logic.	Implement CreatePriorityQueueForBucket and AssignLockPaymentOrder modifications to save/check both current and previous rate queues in Redis as specified in issue #407.
Out of Scope Changes check	⚠️ Warning	The PR includes debug logging statements and unrelated changes to voyager.go event parsing logic that are not connected to the issue #407 requirements for managing previous provider rates.	Remove debug logging code and unrelated refactoring; focus changes exclusively on implementing the previous rate queue persistence mechanism required by issue #407.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title refers to decimal handling improvements but changes involve logging additions and type adjustments for decimals, only partially matching the scope of actual modifications.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/decimals-float64

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6cf43be and 7a81156.

📒 Files selected for processing (1)

• services/voyager.go (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• services/voyager.go

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build-and-test

---

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]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

services/voyager.go (1)

1052-1076: Validate tokenDecimals is a whole number and check int8 overflow risk before casting.

The direct cast of float64 to int8 at line 1076 introduces type safety and overflow concerns:

1. Silent truncation of fractional values: Token decimals represent discrete decimal places (e.g., 6, 18) and must be integers. The current code accepts float64 values without validating they are whole numbers. A value like 18.5 would pass the tokenDecimals <= 0 check and silently truncate to 18 when cast to int8.

2. int8 overflow risk: Casting float64 to int8 (range: -128 to 127) will produce undefined behavior for decimals ≥ 128. While uncommon, the Voyager API returning unexpected values could silently corrupt calculations.

Fix: Validate that tokenDecimals is a whole number and either check the range before casting to int8 or use a larger integer type like int or int16.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f718dcf and 6cf43be.

📒 Files selected for processing (3)

• services/order/starknet.go (2 hunks)
• services/starknet/client.go (1 hunks)
• services/voyager.go (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

services/order/starknet.go (1)

utils/logger/logger.go (3)

• WithFields (76-109)
• Fields (73-73)
• Errorf (141-146)

services/starknet/client.go (1)

utils/logger/logger.go (3)

• WithFields (76-109)
• Fields (73-73)
• Infof (125-130)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build-and-test

🔇 Additional comments (1)

services/starknet/client.go (1)

424-427: LGTM! Good observability enhancement.

The INFO-level logging of order amount components before building the transaction request provides useful operational visibility without exposing sensitive data.