chore: production deployment from main to stable #635
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add validation in InitiatePaymentOrder to reject amounts <= 0 - Add validation to reject rates <= 0 - Add comprehensive test cases for zero and negative values - Fail fast with clear error messages before expensive operations - Prevent invalid orders from being processed on-chain This addresses a security gap where the API would accept zero or negative amounts/rates, only to be rejected at the smart contract level. The new validation provides: 1. Better error messages to users 2. Early failure to save gas and processing time 3. Consistent validation across all entry points
…xports for payment orders (#575) * feat(provider, sender): enhance search functionality and update CSV exports for payment orders * feat(provider): optimize CSV export by caching institution names for lock payment orders * feat(provider, sender): add USD amount column to CSV export for lock payment orders and payment orders * feat(sender): update CSV export to include Amount (USD) in test assertions * feat(provider): update CSV export assertions to include Amount (USD) and Institution * feat(provider): update CSV export to replace Amount (USD) with Fiat Amount * feat(provider, sender): require date range for CSV export in GetLockPaymentOrders and GetPaymentOrders * feat(provider, sender): simplify error response for missing date range in export
* feat(provider): implement payout accounts API endpoints (create, list, delete) with persistence and uniqueness enforcement. * fix(provider): add unique index on payout accounts and update logs * fix(accounts): move provider bank accounts APIs in provider to profile * fix: Remove duplicate ent/user import (keep userkyb); redact PII in logs; map ent.IsConstraintError to 409 Conflict for races. * fix(accounts): add return after error paths in CreateBankAccount to prevent nil deref. * refactor: update provider bank account flow and reusing settings/provider route * fix: remove PII from logs and update terminology for fiat accounts * refactor: rename bankAccounts to fiatAccounts in API response * refactor: update provider fiat account handling and introduce created_at/updated_at fields - Renamed references from provider_fiat_accounts to fiat_accounts across the codebase for consistency. - Added created_at and updated_at fields to the ProviderFiatAccount schema and updated related queries and mutations. - Updated tests to ensure proper handling of the new fields and renamed references. - Enhanced the ProviderProfile and ProviderFiatAccount structures to reflect the changes in naming and field management. * chore: add migration script and update hash values for consistency and integrity * feat(schema/providerfiataccount): make account_name required --------- Co-authored-by: Chibuotu Amadi <[email protected]>
#568) * feat(provider): implement OTC min/max config endpoints and order classification with tests * fix: update route path * refactor: remove duplicate OrderType enum and harden OTC helper * fix: Include OTC check in order creation endpoint * fix: remove duplicate imports * feat: add orderType to InitiatePaymentOrder response. * chore: change otc config from standalone api routes to adding it into the provider profile settings * feat(profile): add validation for OTC configuration in provider profile updates * Refactor ProviderProfile schema and related logic to remove OTC fields - Removed `is_otc_enabled`, `min_otc_value`, and `max_otc_value` fields from the ProviderProfile schema and related files. - Updated the ProviderProfile model, query, and mutation methods to reflect the removal of OTC fields. - Adjusted the ProviderProfile creation and update logic to eliminate references to OTC fields. - Modified the ProviderOrderToken schema to introduce new fields for OTC amounts. - Updated validation and utility functions to accommodate the changes in order type determination based on the new ProviderOrderToken structure. * refactor: otc fields in ProviderOrderToken to remove nil handling - Updated ProviderOrderToken schema to change max and min order amounts for OTC from pointers to values, ensuring they are always required. - Removed nil checks and related methods for OTC fields across mutations and queries. - Adjusted validation logic to reflect the new non-nil requirements for OTC amounts. - Updated related utility functions to handle the new structure of OTC fields. * fix: update OTC fields in ProviderOrderTokenPayload to be required * refactor(tests): add MaxOrderAmountOTC and MinOrderAmountOTC fields to ProviderOrderTokenPayload in profile tests * chore: update migration hash and add new OTC min/max migration script * fix(migrations): set default values for OTC min/max order amounts in provider_order_tokens --------- Co-authored-by: Isaac Onyemaechi Ugwu <[email protected]> Co-authored-by: Chibuotu Amadi <[email protected]>
* feat(profile): add MaxFeeCap support for sender profiles - Introduced MaxFeeCap as an optional field in sender profile updates and retrievals. - Updated tests to validate MaxFeeCap functionality, ensuring it can be set, retrieved, and is correctly handled in payment order calculations. - Enhanced the SenderOrderToken schema and related mutations to accommodate MaxFeeCap, including necessary database migrations. - Implemented logic to enforce MaxFeeCap during fee calculations in payment orders, ensuring compliance with user-defined limits. * fix(sender): enhance MaxFeeCap validation in payment order calculations - Updated the InitiatePaymentOrder method to ensure MaxFeeCap is only applied when it is greater than zero. - Improved validation logic to prevent unnecessary fee calculations when MaxFeeCap is not applicable. - Adjusted related tests to verify the correct handling of MaxFeeCap in various scenarios. * fix(profile): add validation for MaxFeeCap in sender profile updates * refactor(profile, sender): standardize MaxFeeCap handling across profiles and tests - Updated MaxFeeCap to be a required field in sender profile updates and responses, removing nullable handling. - Adjusted validation logic to ensure MaxFeeCap can be zero, indicating no cap, while enforcing positive values when applicable. - Refactored related tests to verify the correct handling of MaxFeeCap, ensuring consistency in assertions and error messages. - Removed unnecessary nil checks and methods related to MaxFeeCap across various components, streamlining the codebase. * chore(migrations): update migration hash and add new max fee cap migration * fix(migrations): set default value for max_fee_cap in sender_order_tokens table --------- Co-authored-by: Chibuotu Amadi <[email protected]>
* feat: implement OTC order management with configurable timeouts - Add ORDER_FULFILLMENT_VALIDITY_OTC, ORDER_REQUEST_VALIDITY_OTC, and ORDER_REFUND_TIMEOUT_OTC configs - Convert all validity/timeout configs to seconds for consistency - Implement OTC order reassignment using Redis keyspace events (similar to regular orders) - Refactor OTC assignment logic into assignOtcOrder helper function - Update refund logic to use OrderRefundTimeoutOtc instead of OrderFulfillmentValidityOtc - Update rate endpoint metadata to use OrderRefundTimeoutOtc - Add sender endpoint for validating fulfilled orders (both OTC and regular) - Add provider guard to FulfillOrder endpoint - Add cleanup for order_exclude_list Redis keys on final states * fix(sender): update order validation to include validated status and enhance OTC order handling * fix(sender): enhance order validation and update payment order status handling - Include order type checks for OTC in ValidateOrder method. - Update payment order status within the transaction to ensure consistency. - Improve error handling for payment order status updates and webhook notifications. - Refactor validation logic to better handle minimum and maximum order amounts for OTC. * test(sender): enhance setup for provider order validation and Redis population - Added creation of ProviderOrderToken for rate validation in setup. - Introduced ProvisionBucket for bucket-based rate validation. - Updated ProviderCurrencies to ensure sufficient balance for validation. - Populated Redis bucket with provider data for validateBucketRate functionality. * refactor(utils): update findSuitableProviderRate to accept context parameter * test: enhance test setup and validation for accounts and profiles - Updated test database client initialization to use shared in-memory schema for consistency across tests. - Introduced mock email service in auth tests to avoid external HTTP calls and improve test reliability. - Enhanced profile tests to create necessary network and token data directly without blockchain dependency. - Improved error handling and validation checks in various test cases to ensure robustness and clarity. - Refactored test cases for better readability and maintainability, ensuring all necessary setups are performed correctly. * test(provider): improve isolated test setup and validation - Updated test database initialization to use unique names per test to prevent locking issues. - Enhanced cleanup logic to ensure proper closure of database and Redis connections, reducing potential errors. - Adjusted assertions in provider tests to reflect accurate expected values for total orders. - Improved error handling in test cases to enhance reliability and clarity. * refactor: remove ganache setup from Makefile and CI workflow - Eliminated ganache-related commands from the Makefile and CI configuration to streamline the testing process. - Updated README to reflect the removal of ganache setup instructions, simplifying the test execution steps. - Refactored test utilities to remove dependencies on local blockchain setup, enhancing test isolation and reliability. - Improved error handling in priority queue service methods for better clarity and robustness. * fix(priority_queue): enhance error handling and cleanup for order key deletion - Added cleanup logic to delete orphaned Redis keys in the assignOtcOrder and sendOrderRequest methods upon failure to set TTL or notify provider. - Improved logging for cleanup operations to provide better visibility into potential issues during error handling. * fix(priority_queue): add Redis key cleanup on transaction failure - Implemented cleanup logic to delete Redis keys in the assignOtcOrder and sendOrderRequest methods when database transactions fail. - Enhanced error handling to ensure proper resource management during transaction failures.
…pe and OTC expiry handling - Added OrderType field to LockPaymentOrderResponse and PaymentOrderResponse structures for better order classification. - Implemented OTC request expiry logic in handleListLockPaymentOrders and AcceptOrder methods based on order status and type. - Updated related response handling to ensure consistency across order management functionalities.
- Refactored the OTC expiry logic in handleListLockPaymentOrders to accommodate different order statuses (Pending and Processing). - Renamed OTCRequestExpiry to OTCExpiry in LockPaymentOrderResponse for clarity and consistency.
* feat(sender): add search and export functionality for payment orders (#562) * feat(sender): add search and export functionality for payment orders - Implemented SearchPaymentOrders controller to allow text-based search across payment orders for authenticated senders. - Added ExportPaymentOrdersCSV controller to enable CSV export of payment orders within a specified date range. - Enhanced routing to include new endpoints for searching and exporting payment orders. - Updated tests to cover new search and export functionalities, ensuring proper validation and response handling. * feat(sender): optimize payment order fetching by batching institution queries and inline transformation * feat(export): add date range validation for CSV export of payment orders * feat(sender): optimize institution fetching in CSV export by eliminating N+1 queries * feat(sender): enhance GetPaymentOrders to support search and export functionality - Refactored GetPaymentOrders to handle search and export requests through query parameters. - Introduced handleSearchPaymentOrders and handleExportPaymentOrders methods for better separation of concerns. - Added applyFilters method to streamline query parameter filtering for payment orders. - Updated response types to include SenderPaymentOrderSearchList for search results. - Adjusted routing to consolidate search and export under the GetPaymentOrders endpoint. - Updated tests to reflect changes in search and export functionality. * Refactor order routes to consolidate search and export functionality - Updated the order routes to handle search and export through a single endpoint. - Modified test cases to reflect changes in the API, ensuring they now use the consolidated endpoint. - Adjusted response messages and payload structures in tests to align with the new functionality. - Ensured all instances of timestamp inclusion in payloads are consistent across tests. * refactor(sender): update order routes to clarify search and export handling * Remove Hedera implementation from aggregator codebase (#579) * Remove Hedera implementation from aggregator codebase - Delete config/hedera.go (HederaConfiguration and HederaConfig) - Delete services/hedera.go (HederaMirrorService and all related methods) - Remove Hedera-specific logic from services/indexer/evm.go: * Remove hederaService field and initialization * Remove chainID == 295 conditional blocks * Remove Hedera from exclusion checks - Remove Hedera-specific logic from services/order/evm.go: * Remove chainID == 295 checks in CreateOrder, SettleOrder, RefundOrder - Clean up all references to chain ID 295 (Hedera's identifier) This removes all Hedera blockchain integration and associated functionality. Closes #578 * Remove unused Hedera-related code and clean up sender controller * feat: add validation to prevent zero or negative amounts and rates - Add validation in InitiatePaymentOrder to reject amounts <= 0 - Add validation to reject rates <= 0 - Add comprehensive test cases for zero and negative values - Fail fast with clear error messages before expensive operations - Prevent invalid orders from being processed on-chain This addresses a security gap where the API would accept zero or negative amounts/rates, only to be rejected at the smart contract level. The new validation provides: 1. Better error messages to users 2. Early failure to save gas and processing time 3. Consistent validation across all entry points * feat(provider, sender): enhance search functionality and update CSV exports for payment orders (#575) * feat(provider, sender): enhance search functionality and update CSV exports for payment orders * feat(provider): optimize CSV export by caching institution names for lock payment orders * feat(provider, sender): add USD amount column to CSV export for lock payment orders and payment orders * feat(sender): update CSV export to include Amount (USD) in test assertions * feat(provider): update CSV export assertions to include Amount (USD) and Institution * feat(provider): update CSV export to replace Amount (USD) with Fiat Amount * feat(provider, sender): require date range for CSV export in GetLockPaymentOrders and GetPaymentOrders * feat(provider, sender): simplify error response for missing date range in export * feat(provider): integrate fiat account management (#573) * feat(provider): implement payout accounts API endpoints (create, list, delete) with persistence and uniqueness enforcement. * fix(provider): add unique index on payout accounts and update logs * fix(accounts): move provider bank accounts APIs in provider to profile * fix: Remove duplicate ent/user import (keep userkyb); redact PII in logs; map ent.IsConstraintError to 409 Conflict for races. * fix(accounts): add return after error paths in CreateBankAccount to prevent nil deref. * refactor: update provider bank account flow and reusing settings/provider route * fix: remove PII from logs and update terminology for fiat accounts * refactor: rename bankAccounts to fiatAccounts in API response * refactor: update provider fiat account handling and introduce created_at/updated_at fields - Renamed references from provider_fiat_accounts to fiat_accounts across the codebase for consistency. - Added created_at and updated_at fields to the ProviderFiatAccount schema and updated related queries and mutations. - Updated tests to ensure proper handling of the new fields and renamed references. - Enhanced the ProviderProfile and ProviderFiatAccount structures to reflect the changes in naming and field management. * chore: add migration script and update hash values for consistency and integrity * feat(schema/providerfiataccount): make account_name required --------- Co-authored-by: Chibuotu Amadi <[email protected]> * feat(provider): implement OTC min/max config endpoints and order clas… (#568) * feat(provider): implement OTC min/max config endpoints and order classification with tests * fix: update route path * refactor: remove duplicate OrderType enum and harden OTC helper * fix: Include OTC check in order creation endpoint * fix: remove duplicate imports * feat: add orderType to InitiatePaymentOrder response. * chore: change otc config from standalone api routes to adding it into the provider profile settings * feat(profile): add validation for OTC configuration in provider profile updates * Refactor ProviderProfile schema and related logic to remove OTC fields - Removed `is_otc_enabled`, `min_otc_value`, and `max_otc_value` fields from the ProviderProfile schema and related files. - Updated the ProviderProfile model, query, and mutation methods to reflect the removal of OTC fields. - Adjusted the ProviderProfile creation and update logic to eliminate references to OTC fields. - Modified the ProviderOrderToken schema to introduce new fields for OTC amounts. - Updated validation and utility functions to accommodate the changes in order type determination based on the new ProviderOrderToken structure. * refactor: otc fields in ProviderOrderToken to remove nil handling - Updated ProviderOrderToken schema to change max and min order amounts for OTC from pointers to values, ensuring they are always required. - Removed nil checks and related methods for OTC fields across mutations and queries. - Adjusted validation logic to reflect the new non-nil requirements for OTC amounts. - Updated related utility functions to handle the new structure of OTC fields. * fix: update OTC fields in ProviderOrderTokenPayload to be required * refactor(tests): add MaxOrderAmountOTC and MinOrderAmountOTC fields to ProviderOrderTokenPayload in profile tests * chore: update migration hash and add new OTC min/max migration script * fix(migrations): set default values for OTC min/max order amounts in provider_order_tokens --------- Co-authored-by: Isaac Onyemaechi Ugwu <[email protected]> Co-authored-by: Chibuotu Amadi <[email protected]> * feat(profile): add MaxFeeCap support for sender profiles (#584) * feat(profile): add MaxFeeCap support for sender profiles - Introduced MaxFeeCap as an optional field in sender profile updates and retrievals. - Updated tests to validate MaxFeeCap functionality, ensuring it can be set, retrieved, and is correctly handled in payment order calculations. - Enhanced the SenderOrderToken schema and related mutations to accommodate MaxFeeCap, including necessary database migrations. - Implemented logic to enforce MaxFeeCap during fee calculations in payment orders, ensuring compliance with user-defined limits. * fix(sender): enhance MaxFeeCap validation in payment order calculations - Updated the InitiatePaymentOrder method to ensure MaxFeeCap is only applied when it is greater than zero. - Improved validation logic to prevent unnecessary fee calculations when MaxFeeCap is not applicable. - Adjusted related tests to verify the correct handling of MaxFeeCap in various scenarios. * fix(profile): add validation for MaxFeeCap in sender profile updates * refactor(profile, sender): standardize MaxFeeCap handling across profiles and tests - Updated MaxFeeCap to be a required field in sender profile updates and responses, removing nullable handling. - Adjusted validation logic to ensure MaxFeeCap can be zero, indicating no cap, while enforcing positive values when applicable. - Refactored related tests to verify the correct handling of MaxFeeCap, ensuring consistency in assertions and error messages. - Removed unnecessary nil checks and methods related to MaxFeeCap across various components, streamlining the codebase. * chore(migrations): update migration hash and add new max fee cap migration * fix(migrations): set default value for max_fee_cap in sender_order_tokens table --------- Co-authored-by: Chibuotu Amadi <[email protected]> * feat(starknet): Implement Starknet client with event handling and transaction management - Added a new Starknet client in `services/starknet/client.go` that wraps the Starknet RPC provider. - Implemented methods for fetching block numbers, events, and transaction receipts. - Added functionality to build and execute transactions, including account deployment and order management. - Introduced event processing for OrderCreated, OrderSettled, OrderRefunded, and ERC20 Transfer events. - Updated `types/types.go` to include structures for Starknet event data and deterministic account information. - Enhanced `utils/rpc_events.go` with Starknet-specific event signatures. * feat(starknet): Update Starknet services and client structure for improved functionality * feat(starknet): Refactor ReceiveAddressService and update SenderController for improved address handling * feat(tests): add comprehensive integration tests for Starknet client using real transaction data * refactor(config, services): update aggregator account naming and remove Starknet configuration - Renamed AGGREGATOR_SMART_ACCOUNT to AGGREGATOR_ACCOUNT_EVM in .env.example and related configurations for clarity. - Removed Starknet configuration and related code, streamlining the services and enhancing maintainability. - Updated ReceiveAddressService and OrderStarknet to utilize the new account naming conventions. - Adjusted SenderController and indexer logic to accommodate the changes in Starknet client initialization. Co-authored-by: Prosper <[email protected]> * feat(indexer, order): enhance Starknet transaction processing and error handling - Updated IndexReceiveAddress and related methods to include userAccountAddress for better transaction context. - Improved error handling for missing parameters and added checks to prevent negative block numbers. - Refactored transaction event processing to handle various data types more robustly, ensuring accurate extraction of transfer data. - Introduced helper functions for extracting felt and big integer values, enhancing code readability and maintainability. - Adjusted CreateOrder and RefundOrder methods to improve error reporting and ensure proper address parsing. This update enhances the overall reliability and clarity of Starknet transaction handling. Co-authored-by: Prosper <[email protected]> * chore(scripts): update generate_test_credentials.sh for improved clarity and organization * chore: update Starknet service files for consistency and maintainability * chore: update Starknet provider URL for improved reliability * fix(starknet): use Equal method for topic comparison in GetEvents * fix(indexer): add conditional logging for improved clarity in transaction processing * feat(tests): add integration tests for Starknet indexer functionality * chore: update comments in client_test.go for clarity and maintainability * feat(starknet): integrate Starknet service for order processing and indexing --------- Co-authored-by: Isaac Onyemaechi Ugwu <[email protected]> Co-authored-by: Onah Sunday. <[email protected]> Co-authored-by: Chibuotu Amadi <[email protected]>
- Increased MaxLen from 60 to 70 characters for address fields - Affected schemas: PaymentOrder, Token, SenderOrderToken - Supports Starknet addresses (66 chars) while maintaining EVM compatibility (42 chars) - Regenerated Ent code with updated validators
- Updated the base image in Dockerfile from golang:1.23.0-bullseye to golang:1.25.5-bookworm. - Updated the base image in Dockerfile.prod from golang:1.23-alpine3.21 to golang:1.25.5-alpine3.23.
#613) * feat(starknet): integrate Voyager service for enhanced transaction processing - Replaced direct Starknet client calls with Voyager service for fetching block numbers, events, and transaction receipts. - Updated IndexReceiveAddress and related methods to utilize Voyager for token transfers and event handling, improving reliability and error handling. - Refactored event processing to filter and transform events from Voyager format to RPC format, ensuring compatibility with existing logic. - Enhanced error messages for better traceability in transaction processing. * feat(voyager): enhance Voyager service integration and configuration - Added Starknet-specific configuration options to .env.example for better service management. - Refactored monthly limit reset logic in Voyager service to improve accuracy and reliability. - Enhanced error handling in API calls to ensure robust data processing and response validation. - Updated item processing in Voyager API calls to handle potential type mismatches and improve data integrity. * fix(voyager): improve monthly limit reset handling and avoid busy-looping * feat(voyager): enhance error handling and improve request processing - Added a field to ensure the Done channel is closed exactly once, preventing potential race conditions. - Updated cleanup logic to utilize for closing the Done channel. - Improved error logging in and methods to provide clearer insights on failures and unexpected data types. - Adjusted event indexing methods to dynamically determine chunk sizes based on provided block ranges, enhancing flexibility in data retrieval. * refactor(indexer): simplify transaction indexing methods by removing unused parameters - Removed unnecessary parameters from indexReceiveAddressByTransaction and indexGatewayByTransaction methods to streamline function signatures. - Updated related method calls to reflect the changes, enhancing code clarity and maintainability. --------- Co-authored-by: onahprosper <[email protected]>
…and lock orders (#612)
* refactor: remove LinkedAddress entity and related references - Deleted the LinkedAddress entity and all associated files, including schema, queries, and mutations. - Removed references to LinkedAddress in PaymentOrder, SenderProfile, and other related entities. - Updated relevant import statements and cleaned up code to ensure no broken references remain. - Adjusted the logic in various services and controllers to reflect the removal of LinkedAddress functionality. * refactor: replace LockPaymentOrder with PaymentOrder across the codebase - Updated references from LockPaymentOrder to PaymentOrder in various files, including schema, queries, and service logic. - Removed LockPaymentOrder related files and adjusted the logic in services and controllers to ensure consistency with the new PaymentOrder structure. - Enhanced the handling of payment orders in the priority queue and other services to reflect the updated naming conventions and relationships. - Cleaned up import statements and ensured that all related tests are updated accordingly to maintain functionality. * refactor(provider): rename ProviderLockOrderList to ProviderOrderList - Updated the response structure for listing and searching provider orders to use ProviderOrderList instead of ProviderLockOrderList for consistency. - Adjusted related API response handling in the ProviderController to reflect the new naming convention. * feat(paymentorder): enhance receive_address field handling - Added functionality to clear and check if the receive_address field is cleared in PaymentOrder mutations and updates. - Introduced SetNillableReceiveAddress method to allow setting the receive_address only if the value is not nil. - Updated schema to make receive_address nullable and adjusted related SQL migration scripts accordingly. - Implemented new predicates for querying based on the receive_address field's presence. * refactor(migration): improve idempotency and data handling in payment order migration - Updated SQL migration script to ensure the entry for 'payment_order_fulfillments' in ent_types is idempotent, preventing duplicate inserts. - Enhanced data migration logic for receive_address and payment_order_recipients to utilize COALESCE for better handling of existing values. - Cleaned up SQL queries to remove unnecessary conditions, streamlining the migration process. * refactor(migration): adjust timing for dropping lock_payment_order_transactions column - Updated SQL migration script to delay the dropping of the lock_payment_order_transactions column until after verification in Step 9.5. - Added comments to clarify the need for the column during verification checks, ensuring data integrity during the migration process. * refactor: streamline payment order handling and remove redundant logging - Simplified receive address creation by directly assigning values instead of using separate ReceiveAddress entity creation (applies to Tron, Starknet, and EVM networks) - Removed unnecessary logging statements in UpdateReceiveAddressStatus function - Refactored IndexGatewayEvents loop: removed unused variable, restructured if/else logic, and fixed log message typo * feat(priority_queue): enhance setup for priority queue tests * fix(provider): unify payment order references in fulfillment logic - Updated references from LockPaymentOrder to PaymentOrder in the FulfillOrder method to ensure consistency across order status checks. - Removed unnecessary linked address retrieval in UpdateOrderStatusRefunded function to streamline order status updates. * refactor(provider): remove ProviderRating schema and related references - Deleted the ProviderRating schema to simplify the provider profile structure. - Removed references to ProviderRating in the ProviderProfile edges. - Updated priority queue service to eliminate sorting by trust score, streamlining provider selection logic. * refactor: unify variable naming and update schema references across multiple entities - Renamed variables in various CRUD operations to use a consistent naming convention, improving code readability and maintainability. - Updated the ProviderProfile schema to include a new edge for provider ratings, enhancing the relationship structure. - Added the ProviderRating schema to establish a clear link between providers and their ratings. - Adjusted related methods and queries to reflect the new naming conventions and schema changes, ensuring consistency throughout the codebase.
…trigger for data migration - Added SQL commands to temporarily disable the enforce_payment_order_amount trigger during data migration steps to allow necessary updates without restrictions. - Re-enabled the trigger after completing all update operations to maintain data integrity.
* refactor: rename LockPaymentOrder to PaymentOrder/ProviderOrder - Rename all function names from LockPaymentOrder to PaymentOrders/ProviderOrder - Rename variable names (lockPaymentOrderQuery, lockPaymentOrders, lockPaymentOrder) to paymentOrder variants - Refactor ProcessPaymentOrderFromBlockchain (formerly CreateLockPaymentOrder) with helper functions - Remove unused LockOrderResponse type - Rename FulfillLockOrderPayload to FulfillOrderPayload - Rename CancelLockOrderPayload to CancelOrderPayload - Update all test files to match new function names - Update router handlers to use new function names - Update comments and error messages to use consistent terminology * refactor: rename LockOrder functions and variables to PaymentOrder - Updated function names and variable references from LockOrder to PaymentOrder for consistency. - Adjusted error messages and comments to reflect the new naming conventions. - Ensured all related logic in fulfillment processes is aligned with the updated terminology. * feat(order): enhance UpdateOrderStatusSettled to include settlement percentage - Added AddPercentSettled method to UpdateOrderStatusSettled for tracking settlement progress. - Updated error handling in validateAndPreparePaymentOrderData to manage token lookup failures and initiate refunds if necessary. - Removed redundant settledPercent variable to streamline the function logic.
- Increased channel timeout from 90s to 120s to account for queue wait time - Added fresh context with 60s timeout for RPC fallback to prevent cascading timeouts - Improved error classification for HTTP 5xx errors to trigger RPC fallback - Enhanced logging with response body for debugging HTTP 500 errors - Fixed context deadline exceeded errors by using separate contexts for RPC fallback This fixes the issue where Voyager API timeouts were cascading to RPC fallback, causing 'context deadline exceeded' errors even when RPC fallback was available.
This reverts commit 2e6cfe5.
- Increased channel timeout from 90s to 120s to account for queue wait time - Added fresh context with 60s timeout for RPC fallback to prevent cascading timeouts - Improved error classification for HTTP 5xx errors to trigger RPC fallback - Enhanced logging with response body for debugging HTTP 500 errors - Fixed context deadline exceeded errors by using separate contexts for RPC fallback This fixes the issue where Voyager API timeouts were cascading to RPC fallback, causing 'context deadline exceeded' errors even when RPC fallback was available.
* fix: improve Voyager service timeout handling and RPC fallback - Increased channel timeout from 90s to 120s to account for queue wait time - Added fresh context with 60s timeout for RPC fallback to prevent cascading timeouts - Improved error classification for HTTP 5xx errors to trigger RPC fallback - Enhanced logging with response body for debugging HTTP 500 errors - Fixed context deadline exceeded errors by using separate contexts for RPC fallback This fixes the issue where Voyager API timeouts were cascading to RPC fallback, causing 'context deadline exceeded' errors even when RPC fallback was available. * fix: implement rate limiting and response handling for Voyager API requests * fix: address rate limit handling for Voyager API to prevent request overload * fix: enhance logging and error handling in Voyager API interactions --------- Co-authored-by: onahprosper <[email protected]>
…erAddress - Fix IndexReceiveAddress to filter transfers by userAccountAddress (to parameter) - Fix IndexProviderAddress to use correct parameter mapping (empty tokenAddress, provider as toAddress) - Update Voyager API URL construction to use ToAddress in path instead of generic Address - Add tokenAddress query parameter for token-specific filtering - Remove redundant 'to' query parameter (now in URL path)
#624) * fix: update indexing logic for Starknet and Voyager services * chore: add logging functionality to improve debugging and monitoring * chore: add logging for processing transfer events in Starknet indexer * chore: normalize Starknet addresses in transfer processing and logging --------- Co-authored-by: onahprosper <[email protected]>
- Added decimal parsing for amounts, protocol fees, rates, settle percentages, rebate percentages, and fees in handleOrderCreated, handleOrderSettled, and handleOrderRefunded methods. - Replaced custom byte array parsing with a utility function in utils.go. - Normalized Starknet addresses in event data for better consistency. - Improved error handling for parsing operations. - Refactored Voyager event transformation to include detailed error handling and support for new data formats. - Updated Voyager API calls to remove unnecessary logging for cleaner output.
…improved accuracy
…tOrderFulfillments
…d currency in payment orders
- Changed the method for fetching the current order to use the correct PaymentOrder service. - Simplified the order status validation to check for pending status only, improving clarity and maintainability.
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ 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 |
onahprosper
approved these changes
Dec 23, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Production Deployment: Main → Stable
This PR includes all changes from main branch ready for production deployment.
🚀 New Features & Enhancements
🔧 Key Improvements
🐛 Bug Fixes
🔄 Refactoring
📊 Monitoring & Debugging
📝 Technical Details