-
Notifications
You must be signed in to change notification settings - Fork 97
Merge back bug fixes from 2.1.5 #6747
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Teebor-Choka
commented
Dec 18, 2024
- Fix backwards compatibility of the withdraw endpoint in currency
📝 WalkthroughWalkthroughThe pull request introduces modifications to the Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (2)
hoprd/rest-api/src/account.rs (2)
137-148
: Add test cases for case-sensitive deserializationThe function correctly handles both "Native" and "NATIVE" cases, improving backwards compatibility. However, the test suite only verifies the "HOPR" case.
Consider adding these test cases to verify all supported formats:
#[test] fn test_balance_type_deserialization() -> anyhow::Result<()> { // Test existing format let hopr: WithdrawBodyRequest = serde_json::from_str(r#"{"currency": "HOPR", "amount": "20000", "address": "0xb4ce7e6e36ac8b01a974725d5ba730af2b156fbe"}"#)?; assert_eq!(hopr.currency, BalanceType::HOPR); // Test both native formats let native: WithdrawBodyRequest = serde_json::from_str(r#"{"currency": "Native", "amount": "20000", "address": "0xb4ce7e6e36ac8b01a974725d5ba730af2b156fbe"}"#)?; assert_eq!(native.currency, BalanceType::Native); let native_upper: WithdrawBodyRequest = serde_json::from_str(r#"{"currency": "NATIVE", "amount": "20000", "address": "0xb4ce7e6e36ac8b01a974725d5ba730af2b156fbe"}"#)?; assert_eq!(native_upper.currency, BalanceType::Native); // Test error case let error = serde_json::from_str::<WithdrawBodyRequest>(r#"{"currency": "invalid", "amount": "20000", "address": "0xb4ce7e6e36ac8b01a974725d5ba730af2b156fbe"}"#); assert!(error.is_err()); Ok(()) }
159-160
: Update schema example to document all supported formatsThe schema example only shows one format ("HOPR"), but the API now supports multiple formats for the currency field ("Native"/"NATIVE").
Update the schema example to document all supported formats:
#[schema(example = json!({ "address": "0xb4ce7e6e36ac8b01a974725d5ba730af2b156fbe", "amount": "20000", - "currency": "HOPR" + "currency": "HOPR" // Supported values: "HOPR", "Native", "NATIVE" }))]
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
hoprd/rest-api/src/account.rs
(2 hunks)
🔇 Additional comments (1)
hoprd/rest-api/src/account.rs (1)
Line range hint 137-160
: Verify existing API usage patterns
Let's verify how the withdraw endpoint is currently being used to ensure we maintain compatibility.
✅ Verification successful
Based on the gathered information, I can now provide the final response:
Backwards compatibility is maintained for the withdraw endpoint
The changes to the balance type deserialization maintain compatibility with existing clients:
- The Python client implementation in
tests/hopr.py
uses the string format for currency ("Native" or "HOPR") - Integration tests in
test_integration.py
demonstrate working functionality with "Native" currency type - The deserializer explicitly handles both "Native" and "NATIVE" case variants, ensuring backward compatibility
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for withdraw endpoint usage in tests and examples
rg -A 2 -B 2 'currency.*(?:NATIVE|Native|HOPR)' --type rust
# Search for any HTTP client implementations that might be using the endpoint
rg -A 5 '/account/withdraw' --type typescript --type javascript --type python
Length of output: 1309
Script:
#!/bin/bash
# Let's search for test files and client implementations with more inclusive patterns
rg -A 5 "withdraw" --type rust
# Search for any HTTP client implementations with proper file extensions
rg -A 5 '/account/withdraw' -g '*.ts' -g '*.js' -g '*.py'
# Look for API tests specifically
fd -e test.ts -e test.js -e test.py -e test.rs | xargs rg -l "withdraw"
# Check for any OpenAPI/Swagger definitions that might document the endpoint
fd -e yaml -e json | xargs rg -l "withdraw"
Length of output: 42318
Script:
#!/bin/bash
# Let's check for test files that specifically test the withdraw endpoint
rg -A 5 -B 5 "test.*withdraw" tests/
# Look for any Python client usage of the withdraw endpoint
rg -A 5 "withdraw" tests/hopr.py
# Check for any API documentation or OpenAPI specs
fd -e yaml -e json | xargs rg -A 5 "/account/withdraw"
Length of output: 1287
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
hoprd/rest-api/src/account.rs (1)
Line range hint
223-242
: Add test cases for backwards compatibilityThe current test only covers the "HOPR" case. To ensure backwards compatibility, we should add test cases for both "Native" and "NATIVE" variants.
Add these test cases:
#[test] fn withdraw_input_should_support_native_variants() -> anyhow::Result<()> { // Test lowercase "Native" let native: WithdrawBodyRequest = serde_json::from_str( r#"{ "currency": "Native", "amount": "20000", "address": "0xb4ce7e6e36ac8b01a974725d5ba730af2b156fbe"}"#, )?; assert_eq!(native.currency, BalanceType::Native); // Test uppercase "NATIVE" let NATIVE: WithdrawBodyRequest = serde_json::from_str( r#"{ "currency": "NATIVE", "amount": "20000", "address": "0xb4ce7e6e36ac8b01a974725d5ba730af2b156fbe"}"#, )?; assert_eq!(NATIVE.currency, BalanceType::Native); Ok(()) }
🧹 Nitpick comments (2)
hoprd/rest-api/src/account.rs (2)
143-147
: Improve error message for invalid balance typesThe error message for invalid balance types could be more helpful by listing the supported values.
- _ => Err(serde::de::Error::custom("Unsupported balance type")), + _ => Err(serde::de::Error::custom("Unsupported balance type. Expected 'Native', 'NATIVE', or 'HOPR'")),
159-160
: Remove commented-out codeThe old implementation using
DisplayFromStr
should be removed rather than commented out, as it's being replaced by the new deserialization approach.- // #[serde_as(as = "DisplayFromStr")] #[serde(deserialize_with = "deserialize_balance_type")]
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
hoprd/rest-api/src/account.rs
(2 hunks)
🔇 Additional comments (1)
hoprd/rest-api/src/account.rs (1)
137-148
: Verify all currency field usages in the codebase
Let's ensure there are no other places in the codebase that might be affected by this change in currency field deserialization.
✅ Verification successful
Let me gather more context about the BalanceType
usage to ensure we have a complete picture.
Based on the comprehensive search results, I can now provide a final response regarding the currency field deserialization changes:
Currency field deserialization changes are properly contained
The implementation of deserialize_balance_type
in hoprd/rest-api/src/account.rs
is the only place where currency/balance type deserialization is handled in the REST API. All other usages of BalanceType
in the codebase are internal enum usages that are not affected by the deserialization changes.
- The change only affects how external JSON requests are parsed in the REST API
- All internal usages of
BalanceType
use the enum variants directly - No other parts of the codebase rely on string-based deserialization of balance types
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for potential currency field usages that might need similar handling
rg -l 'currency.*BalanceType' --type rust
# Search for similar struct definitions that might need the same treatment
ast-grep --pattern 'struct $_ {
$$$
currency: BalanceType,
$$$
}'
Length of output: 286
Script:
#!/bin/bash
# Search for all BalanceType usages and their context
rg -A 5 -B 5 'BalanceType' --type rust
# Search for any serialization/deserialization of BalanceType
ast-grep --pattern 'impl $_ for BalanceType'
Length of output: 108220