Release/release v140 to master - #311
Merged
Merged
Conversation
Fix/sync dev with master 110
…alization_logic (feat) Cleaned up the markets initialization logic
…o fix/sync_dev_with_master_1_12_0
…_12_0 Fix/sync dev with master 1.12.0
…Added the use of `dotenv` to load private keys into environment variables. Removed `asyncio` package dependency
…o feat/use_dot_env_in_examples
Feat/use dot env in examples
…o new example scripts for all queries and unit tests
…the `distribution` module. Marked as deprecated old functions not following Python naming standards and created the replacements for them (with the correct name following standards)
…Added the use of `dotenv` to load private keys into environment variables. Removed `asyncio` package dependency
…o feat/sync_dev_with_master_130
Feat/sync dev with master 1.3.0
…o new example scripts for all queries and unit tests
…the `distribution` module. Marked as deprecated old functions not following Python naming standards and created the replacements for them (with the correct name following standards)
…//github.com/InjectiveLabs/sdk-python into feat/add_distribution_module_queries_support
…le_queries_support Feat/add distribution module queries support
…new example scripts for all the queries and unit tests.
…er. Added unit tests for new messages. Refactored example scripts to move them into separated subfolders for each module.
…dule_support Feat/add chain exchange module support
…Added the use of `dotenv` to load private keys into environment variables. Removed `asyncio` package dependency
…Added the use of `dotenv` to load private keys into environment variables. Removed `asyncio` package dependency
…o new example scripts for all queries and unit tests
…the `distribution` module. Marked as deprecated old functions not following Python naming standards and created the replacements for them (with the correct name following standards)
…new example scripts for all the queries and unit tests.
…er. Added unit tests for new messages. Refactored example scripts to move them into separated subfolders for each module.
…new example scripts for all the queries and unit tests.
…er. Added unit tests for new messages. Refactored example scripts to move them into separated subfolders for each module.
…ule: TradeRewardCampaign
…o feat/add_trade_reward_campaign_endpoint
…aign_endpoint Feat/add trade reward campaign endpoint
fix/fix_example_script_errors
Contributor
WalkthroughThe update to version 1.4.0 introduces a significant overhaul aimed at enhancing security, flexibility, and functionality. Key improvements include the adoption of Changes
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #311 +/- ##
==========================================
+ Coverage 72.81% 76.16% +3.34%
==========================================
Files 48 50 +2
Lines 3384 4111 +727
Branches 303 351 +48
==========================================
+ Hits 2464 3131 +667
- Misses 839 875 +36
- Partials 81 105 +24 ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://cdn.github.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Review Status
Actionable comments generated: 40
Configuration used: .coderabbit.yaml
Files selected for processing (140)
- .coderabbit.yaml (1 hunks)
- CHANGELOG.md (1 hunks)
- examples/SendToInjective.py (1 hunks)
- examples/chain_client/1_LocalOrderHash.py (8 hunks)
- examples/chain_client/3_MessageBroadcaster.py (3 hunks)
- examples/chain_client/4_MessageBroadcasterWithGranteeAccount.py (4 hunks)
- examples/chain_client/5_MessageBroadcasterWithoutSimulation.py (3 hunks)
- examples/chain_client/6_MessageBroadcasterWithGranteeAccountWithoutSimulation.py (4 hunks)
- examples/chain_client/auction/1_MsgBid.py (4 hunks)
- examples/chain_client/authz/1_MsgGrant.py (5 hunks)
- examples/chain_client/authz/2_MsgExec.py (4 hunks)
- examples/chain_client/authz/3_MsgRevoke.py (4 hunks)
- examples/chain_client/authz/query/1_Grants.py (1 hunks)
- examples/chain_client/bank/1_MsgSend.py (4 hunks)
- examples/chain_client/distribution/1_SetWithdrawAddress.py (1 hunks)
- examples/chain_client/distribution/2_WithdrawDelegatorReward.py (1 hunks)
- examples/chain_client/distribution/3_WithdrawValidatorCommission.py (1 hunks)
- examples/chain_client/distribution/4_FundCommunityPool.py (1 hunks)
- examples/chain_client/distribution/query/1_ValidatorDistributionInfo.py (1 hunks)
- examples/chain_client/distribution/query/2_ValidatorOutstandingRewards.py (1 hunks)
- examples/chain_client/distribution/query/3_ValidatorCommission.py (1 hunks)
- examples/chain_client/distribution/query/4_ValidatorSlashes.py (1 hunks)
- examples/chain_client/distribution/query/5_DelegationRewards.py (1 hunks)
- examples/chain_client/distribution/query/6_DelegationTotalRewards.py (1 hunks)
- examples/chain_client/distribution/query/7_DelegatorValidators.py (1 hunks)
- examples/chain_client/distribution/query/8_DelegatorWithdrawAddress.py (1 hunks)
- examples/chain_client/distribution/query/9_CommunityPool.py (1 hunks)
- examples/chain_client/exchange/10_MsgCreateDerivativeLimitOrder.py (5 hunks)
- examples/chain_client/exchange/11_MsgCreateDerivativeMarketOrder.py (5 hunks)
- examples/chain_client/exchange/12_MsgCancelDerivativeOrder.py (5 hunks)
- examples/chain_client/exchange/13_MsgInstantBinaryOptionsMarketLaunch.py (1 hunks)
- examples/chain_client/exchange/14_MsgCreateBinaryOptionsLimitOrder.py (5 hunks)
- examples/chain_client/exchange/15_MsgCreateBinaryOptionsMarketOrder.py (5 hunks)
- examples/chain_client/exchange/16_MsgCancelBinaryOptionsOrder.py (5 hunks)
- examples/chain_client/exchange/17_MsgSubaccountTransfer.py (4 hunks)
- examples/chain_client/exchange/18_MsgExternalTransfer.py (4 hunks)
- examples/chain_client/exchange/19_MsgLiquidatePosition.py (5 hunks)
- examples/chain_client/exchange/1_MsgDeposit.py (3 hunks)
- examples/chain_client/exchange/20_MsgIncreasePositionMargin.py (5 hunks)
- examples/chain_client/exchange/21_MsgRewardsOptOut.py (4 hunks)
- examples/chain_client/exchange/22_MsgAdminUpdateBinaryOptionsMarket.py (4 hunks)
- examples/chain_client/exchange/2_MsgWithdraw.py (4 hunks)
- examples/chain_client/exchange/3_MsgInstantSpotMarketLaunch.py (1 hunks)
- examples/chain_client/exchange/4_MsgInstantPerpetualMarketLaunch.py (1 hunks)
- examples/chain_client/exchange/5_MsgInstantExpiryFuturesMarketLaunch.py (1 hunks)
- examples/chain_client/exchange/6_MsgCreateSpotLimitOrder.py (5 hunks)
- examples/chain_client/exchange/7_MsgCreateSpotMarketOrder.py (5 hunks)
- examples/chain_client/exchange/8_MsgCancelSpotOrder.py (4 hunks)
- examples/chain_client/exchange/9_MsgBatchUpdateOrders.py (5 hunks)
- examples/chain_client/exchange/query/10_SpotMarkets.py (1 hunks)
- examples/chain_client/exchange/query/11_SpotMarket.py (1 hunks)
- examples/chain_client/exchange/query/12_FullSpotMarkets.py (1 hunks)
- examples/chain_client/exchange/query/13_FullSpotMarket.py (1 hunks)
- examples/chain_client/exchange/query/14_SpotOrderbook.py (1 hunks)
- examples/chain_client/exchange/query/15_TraderSpotOrders.py (1 hunks)
- examples/chain_client/exchange/query/16_AccountAddressSpotOrders.py (1 hunks)
- examples/chain_client/exchange/query/17_SpotOrdersByHashes.py (1 hunks)
- examples/chain_client/exchange/query/18_SubaccountOrders.py (1 hunks)
- examples/chain_client/exchange/query/19_TraderSpotTransientOrders.py (1 hunks)
- examples/chain_client/exchange/query/1_SubaccountDeposits.py (1 hunks)
- examples/chain_client/exchange/query/20_SpotMidPriceAndTOB.py (1 hunks)
- examples/chain_client/exchange/query/21_DerivativeMidPriceAndTOB.py (1 hunks)
- examples/chain_client/exchange/query/22_DerivativeOrderbook.py (1 hunks)
- examples/chain_client/exchange/query/23_TraderDerivativeOrders.py (1 hunks)
- examples/chain_client/exchange/query/24_AccountAddressDerivativeOrders.py (1 hunks)
- examples/chain_client/exchange/query/25_DerivativeOrdersByHashes.py (1 hunks)
- examples/chain_client/exchange/query/26_TraderDerivativeTransientOrders.py (1 hunks)
- examples/chain_client/exchange/query/27_DerivativeMarkets.py (1 hunks)
- examples/chain_client/exchange/query/28_DerivativeMarket.py (1 hunks)
- examples/chain_client/exchange/query/29_DerivativeMarketAddress.py (1 hunks)
- examples/chain_client/exchange/query/2_SubaccountDeposit.py (1 hunks)
- examples/chain_client/exchange/query/30_SubaccountTradeNonce.py (1 hunks)
- examples/chain_client/exchange/query/31_Positions.py (1 hunks)
- examples/chain_client/exchange/query/32_SubaccountPositions.py (1 hunks)
- examples/chain_client/exchange/query/33_SubaccountPositionInMarket.py (1 hunks)
- examples/chain_client/exchange/query/34_SubaccountEffectivePositionInMarket.py (1 hunks)
- examples/chain_client/exchange/query/35_PerpetualMarketInfo.py (1 hunks)
- examples/chain_client/exchange/query/36_ExpiryFuturesMarketInfo.py (1 hunks)
- examples/chain_client/exchange/query/37_PerpetualMarketFunding.py (1 hunks)
- examples/chain_client/exchange/query/38_SubaccountOrderMetadata.py (1 hunks)
- examples/chain_client/exchange/query/39_TradeRewardPoints.py (1 hunks)
- examples/chain_client/exchange/query/3_ExchangeBalances.py (1 hunks)
- examples/chain_client/exchange/query/40_PendingTradeRewardPoints.py (1 hunks)
- examples/chain_client/exchange/query/41_TradeRewardCampaign.py (1 hunks)
- examples/chain_client/exchange/query/42_FeeDiscountAccountInfo.py (1 hunks)
- examples/chain_client/exchange/query/43_FeeDiscountSchedule.py (1 hunks)
- examples/chain_client/exchange/query/44_BalanceMismatches.py (1 hunks)
- examples/chain_client/exchange/query/45_BalanceWithBalanceHolds.py (1 hunks)
- examples/chain_client/exchange/query/46_FeeDiscountTierStatistics.py (1 hunks)
- examples/chain_client/exchange/query/47_MitoVaultInfos.py (1 hunks)
- examples/chain_client/exchange/query/48_QueryMarketIDFromVault.py (1 hunks)
- examples/chain_client/exchange/query/49_HistoricalTradeRecords.py (1 hunks)
- examples/chain_client/exchange/query/4_AggregateVolume.py (1 hunks)
- examples/chain_client/exchange/query/50_IsOptedOutOfRewards.py (1 hunks)
- examples/chain_client/exchange/query/51_OptedOutOfRewardsAccounts.py (1 hunks)
- examples/chain_client/exchange/query/52_MarketVolatility.py (1 hunks)
- examples/chain_client/exchange/query/53_BinaryOptionsMarkets.py (1 hunks)
- examples/chain_client/exchange/query/54_TraderDerivativeConditionalOrders.py (1 hunks)
- examples/chain_client/exchange/query/55_MarketAtomicExecutionFeeMultiplier.py (1 hunks)
- examples/chain_client/exchange/query/5_AggregateVolumes.py (1 hunks)
- examples/chain_client/exchange/query/6_AggregateMarketVolume.py (1 hunks)
- examples/chain_client/exchange/query/7_AggregateMarketVolumes.py (1 hunks)
- examples/chain_client/exchange/query/8_DenomDecimal.py (1 hunks)
- examples/chain_client/exchange/query/9_DenomDecimals.py (1 hunks)
- examples/chain_client/insurance/1_MsgCreateInsuranceFund.py (4 hunks)
- examples/chain_client/insurance/2_MsgUnderwrite.py (4 hunks)
- examples/chain_client/insurance/3_MsgRequestRedemption.py (4 hunks)
- examples/chain_client/oracle/1_MsgRelayPriceFeedPrice.py (4 hunks)
- examples/chain_client/oracle/2_MsgRelayProviderPrices.py (4 hunks)
- examples/chain_client/peggy/1_MsgSendToEth.py (4 hunks)
- examples/chain_client/staking/1_MsgDelegate.py (4 hunks)
- examples/chain_client/tokenfactory/1_CreateDenom.py (2 hunks)
- examples/chain_client/tokenfactory/2_MsgMint.py (3 hunks)
- examples/chain_client/tokenfactory/3_MsgBurn.py (3 hunks)
- examples/chain_client/tokenfactory/4_MsgChangeAdmin.py (2 hunks)
- examples/chain_client/tokenfactory/5_MsgSetDenomMetadata.py (2 hunks)
- examples/chain_client/wasm/1_MsgExecuteContract.py (4 hunks)
- examples/chain_client/wasmx/1_MsgExecuteContractCompat.py (4 hunks)
- poetry.lock (16 hunks)
- pyinjective/async_client.py (6 hunks)
- pyinjective/client/chain/grpc/chain_grpc_distribution_api.py (1 hunks)
- pyinjective/client/chain/grpc/chain_grpc_exchange_api.py (1 hunks)
- pyinjective/composer.py (24 hunks)
- pyinjective/core/broadcaster.py (2 hunks)
- pyinjective/core/market.py (1 hunks)
- pyinjective/denoms_devnet.ini (3 hunks)
- pyinjective/denoms_mainnet.ini (12 hunks)
- pyinjective/denoms_testnet.ini (5 hunks)
- pyproject.toml (2 hunks)
- tests/client/chain/grpc/configurable_distribution_query_servicer.py (1 hunks)
- tests/client/chain/grpc/configurable_exchange_query_servicer.py (1 hunks)
- tests/client/chain/grpc/test_chain_grpc_authz_api.py (1 hunks)
- tests/client/chain/grpc/test_chain_grpc_distribution_api.py (1 hunks)
- tests/core/test_gas_limit_estimator.py (12 hunks)
- tests/core/test_market.py (1 hunks)
- tests/core/test_message_based_transaction_fee_calculator.py (3 hunks)
- tests/test_async_client_deprecation_warnings.py (1 hunks)
- tests/test_composer.py (5 hunks)
- tests/test_composer_deprecation_warnings.py (1 hunks)
- tests/test_orderhash.py (2 hunks)
Files not summarized due to errors (3)
- poetry.lock: Error: Message exceeds token limit
- pyinjective/composer.py: Error: Message exceeds token limit
- tests/test_composer.py: Error: Message exceeds token limit
Files not reviewed due to errors (10)
- examples/chain_client/exchange/6_MsgCreateSpotLimitOrder.py (Error: unable to parse review)
- examples/chain_client/authz/1_MsgGrant.py (Error: unable to parse review)
- examples/chain_client/exchange/15_MsgCreateBinaryOptionsMarketOrder.py (Error: unable to parse review)
- examples/chain_client/exchange/10_MsgCreateDerivativeLimitOrder.py (Error: unable to parse review)
- examples/chain_client/exchange/11_MsgCreateDerivativeMarketOrder.py (Error: unable to parse review)
- examples/chain_client/exchange/14_MsgCreateBinaryOptionsLimitOrder.py (Error: unable to parse review)
- examples/chain_client/authz/2_MsgExec.py (Error: unable to parse review)
- examples/chain_client/exchange/19_MsgLiquidatePosition.py (Error: unable to parse review)
- pyinjective/client/chain/grpc/chain_grpc_distribution_api.py (Error: unable to parse review)
- examples/chain_client/exchange/9_MsgBatchUpdateOrders.py (Error: unable to parse review)
Additional comments: 321
.coderabbit.yaml (1)
- 1-8: The configuration for automated reviews and replies looks good and is a welcome addition to streamline the review process. However, please verify:
- The regex pattern
feat/.*correctly matches the intended feature branch naming convention.- The auto-reply feature in chat is intended for all interactions, as it might not be suitable for all types of communications.
examples/chain_client/distribution/query/9_CommunityPool.py (1)
- 1-15: The script for querying the community pool looks well-implemented and aligns with the project's objectives for enhanced functionality. Please ensure that error handling in the
AsyncClientandNetworkclasses is robust, especially for network-related errors, assuming this is managed upstream.examples/chain_client/exchange/query/47_MitoVaultInfos.py (1)
- 1-15: The script for querying Mito Vault information is well-structured and serves its purpose effectively. Consider adding documentation or comments on how to adapt this script for different network environments (e.g., mainnet), ensuring flexibility for various use cases.
examples/chain_client/exchange/query/3_ExchangeBalances.py (1)
- 1-14: The script for querying exchange balances is clear and aligns with the project's enhancement objectives. As with previous scripts, please ensure there's guidance on adapting the script for different network environments to maintain flexibility.
examples/chain_client/exchange/query/31_Positions.py (1)
- 1-15: The script for querying chain positions is effectively implemented and contributes to the project's objectives. Please continue to provide guidance on adapting the script for different network environments, ensuring it remains flexible for various use cases.
examples/chain_client/exchange/query/43_FeeDiscountSchedule.py (1)
- 1-15: The script for querying the fee discount schedule is well-structured and meets the project's enhancement goals. As with other scripts, guidance on adapting for different network environments would be beneficial to ensure flexibility.
examples/chain_client/exchange/query/45_BalanceWithBalanceHolds.py (1)
- 1-15: The script for querying balances with balance holds is effectively implemented and aligns with the project's objectives. Continuing the theme, please ensure there's guidance on adapting the script for different network environments.
examples/chain_client/exchange/query/51_OptedOutOfRewardsAccounts.py (1)
- 1-15: The script for querying accounts that have opted out of rewards is well-structured and contributes to the project's enhancement goals. Please continue to provide guidance on adapting the script for different network environments.
examples/chain_client/exchange/query/46_FeeDiscountTierStatistics.py (1)
- 1-15: The script for querying fee discount tier statistics is effectively implemented and aligns with the project's objectives. As with other scripts, guidance on adapting the script for different network environments would be beneficial.
examples/chain_client/exchange/query/44_BalanceMismatches.py (1)
- 1-15: The script for querying balance mismatches is well-structured and meets the project's enhancement goals. Continuing the theme, please ensure there's guidance on adapting the script for different network environments.
examples/chain_client/exchange/query/53_BinaryOptionsMarkets.py (1)
- 1-19: - The script is well-structured and follows good practices for asynchronous programming in Python.
- The use of
Network.testnet()directly in the script limits its flexibility. Consider allowing the network type (local, testnet, mainnet) to be passed as an argument or read from a configuration file or environment variable for greater flexibility.- Ensure that the
AsyncClientand thefetch_chain_binary_options_marketsmethod handle errors gracefully. It's important to catch exceptions that may arise from network issues or invalid responses and provide meaningful error messages to the user.- Adding a brief comment or documentation at the top of the script explaining its purpose and usage would enhance its maintainability and usability for new developers or users.
examples/chain_client/distribution/query/3_ValidatorCommission.py (1)
- 1-16: - The script is concise and follows good practices for asynchronous programming in Python.
- The hardcoded
validator_addresslimits the script's flexibility. Consider allowing the validator address to be passed as an argument or read from a configuration file or environment variable to make the script more versatile.- Similar to the previous file, ensure that the
AsyncClientand thefetch_validator_commissionmethod handle errors gracefully. Proper error handling is crucial for a robust script.- Adding a brief comment or documentation at the top of the script explaining its purpose, usage, and the expected format of the
validator_addresswould improve its maintainability and usability.examples/chain_client/distribution/query/2_ValidatorOutstandingRewards.py (1)
- 1-16: - The script is consistent with the previous ones in terms of structure and coding practices.
- As with the previous scripts, consider enhancing flexibility by allowing the
validator_addressto be passed as an argument or read from a configuration file or environment variable.- Ensure robust error handling for the
AsyncClientand thefetch_validator_outstanding_rewardsmethod to handle potential exceptions gracefully.- Adding documentation at the top of the script to explain its purpose, usage, and the expected format of the
validator_addresswould be beneficial for maintainability and user guidance.examples/chain_client/distribution/query/6_DelegationTotalRewards.py (1)
- 1-18: - This script, similar to the previous ones, is well-structured and follows good asynchronous programming practices.
- The hardcoded
delegator_addresslimits the script's flexibility. Allowing this address to be dynamically specified, either through command-line arguments or environment variables, would make the script more versatile.- Ensure that error handling is robust for both the
AsyncClientinitialization and thefetch_delegation_total_rewardsmethod to gracefully manage potential exceptions.- Adding documentation at the top of the script to explain its purpose, usage, and the expected format of the
delegator_addresswould enhance its maintainability and provide valuable guidance to users.examples/chain_client/distribution/query/7_DelegatorValidators.py (1)
- 1-18: - The script is consistent with the previous ones in terms of structure and coding practices.
- The hardcoded
delegator_addresslimits the script's flexibility. Consider allowing this address to be dynamically specified to enhance the script's usability.- Robust error handling for the
AsyncClientand thefetch_delegator_validatorsmethod is essential to ensure the script can handle potential exceptions gracefully.- Adding documentation at the top of the script to explain its purpose, usage, and the expected format of the
delegator_addresswould be beneficial for both maintainability and user guidance.examples/chain_client/distribution/query/1_ValidatorDistributionInfo.py (1)
- 1-16: - This script follows the established pattern of good asynchronous programming practices seen in the previous scripts.
- The hardcoded
validator_addresslimits the script's flexibility. Allowing this address to be dynamically specified would enhance the script's usability.- Ensure robust error handling for the
AsyncClientand thefetch_validator_distribution_infomethod to manage potential exceptions effectively.- Adding documentation at the top of the script to explain its purpose, usage, and the expected format of the
validator_addresswould improve its maintainability and provide valuable guidance to users.examples/chain_client/exchange/query/8_DenomDecimal.py (1)
- 1-19: - The script is well-structured and follows good practices for asynchronous programming in Python.
- The hardcoded
denomvalue limits the script's flexibility. Consider allowing the denom to be passed as an argument or read from a configuration file or environment variable for greater flexibility.- Ensure that the
AsyncClientand thefetch_denom_decimalmethod handle errors gracefully. It's important to catch exceptions that may arise from network issues or invalid responses and provide meaningful error messages to the user.- Adding a brief comment or documentation at the top of the script explaining its purpose and usage would enhance its maintainability and usability for new developers or users.
examples/chain_client/exchange/query/9_DenomDecimals.py (1)
- 1-19: - The script is consistent with the previous ones in terms of structure and coding practices.
- The hardcoded
denomslist limits the script's flexibility. Consider allowing this list to be dynamically specified to enhance the script's usability.- Robust error handling for the
AsyncClientand thefetch_denom_decimalsmethod is essential to ensure the script can handle potential exceptions gracefully.- Adding documentation at the top of the script to explain its purpose, usage, and how to specify the
denomswould be beneficial for both maintainability and user guidance.examples/chain_client/distribution/query/8_DelegatorWithdrawAddress.py (1)
- 1-18: - This script follows the established pattern of good asynchronous programming practices seen in the previous scripts.
- The hardcoded
delegator_addresslimits the script's flexibility. Allowing this address to be dynamically specified would enhance the script's usability.- Ensure robust error handling for the
AsyncClientand thefetch_delegator_withdraw_addressmethod to manage potential exceptions effectively.- Adding documentation at the top of the script to explain its purpose, usage, and the expected format of the
delegator_addresswould improve its maintainability and provide valuable guidance to users.examples/chain_client/exchange/query/48_QueryMarketIDFromVault.py (1)
- 1-19: - The script is well-structured and follows good practices for asynchronous programming in Python.
- The hardcoded
vault_addresslimits the script's flexibility. Consider allowing the vault address to be passed as an argument or read from a configuration file or environment variable for greater flexibility.- Ensure that the
AsyncClientand thefetch_market_id_from_vaultmethod handle errors gracefully. It's important to catch exceptions that may arise from network issues or invalid responses and provide meaningful error messages to the user.- Adding a brief comment or documentation at the top of the script explaining its purpose and usage would enhance its maintainability and usability for new developers or users.
examples/chain_client/exchange/query/28_DerivativeMarket.py (1)
- 1-21: - The script
28_DerivativeMarket.pyis well-structured and follows good practices for asynchronous programming in Python. It correctly initializes theAsyncClientand uses it to fetch a derivative market by its ID.
- It's important to ensure that the
market_idused in the script is valid and corresponds to an existing market in the Injective Protocol. If this ID is just for example purposes, consider adding a comment to clarify that users should replace it with a valid market ID.- Consider adding error handling around the
await client.fetch_chain_derivative_marketcall to gracefully handle any potential issues that might arise during the API call, such as network issues or invalid market IDs.examples/chain_client/exchange/query/55_MarketAtomicExecutionFeeMultiplier.py (1)
- 1-21: - The script
55_MarketAtomicExecutionFeeMultiplier.pyis well-structured and follows good practices for asynchronous programming in Python. It correctly initializes theAsyncClientand uses it to fetch the atomic execution fee multiplier for a specific market by its ID.
- Similar to the previous script, ensure that the
market_idused is valid and corresponds to an existing market. If this ID is for example purposes, adding a comment for clarification would be beneficial.- Adding error handling around the
await client.fetch_market_atomic_execution_fee_multipliercall would improve the robustness of the script by gracefully handling potential issues during the API call.examples/chain_client/exchange/query/10_SpotMarkets.py (1)
- 1-22: - The script
10_SpotMarkets.pyeffectively demonstrates how to query spot markets based on specific criteria (e.g., status and market IDs) using theAsyncClient.
- Ensure the
market_idsarray contains valid market IDs. If these IDs are placeholders, it would be helpful to add a comment indicating that users should replace them with actual market IDs.- Adding error handling for the
await client.fetch_chain_spot_marketscall would enhance the script's reliability by addressing potential issues such as network errors or invalid parameters.examples/chain_client/distribution/query/5_DelegationRewards.py (1)
- 1-19: - The script
5_DelegationRewards.pyis well-structured and demonstrates how to query delegation rewards using theAsyncClient. It correctly initializes the client and fetches rewards for a specified delegator and validator.
- It's crucial to ensure that the
delegator_addressandvalidator_addressare valid. If these addresses are placeholders for demonstration purposes, adding a comment to clarify that users should replace them with actual addresses would be beneficial.- Consider adding error handling around the
await client.fetch_delegation_rewardscall to improve the script's robustness by handling potential issues such as invalid addresses or network errors.examples/chain_client/exchange/query/13_FullSpotMarket.py (1)
- 1-22: - The script
13_FullSpotMarket.pyeffectively demonstrates querying detailed information about a specific spot market, including mid-price and top of the book (TOB), using theAsyncClient.
- As with previous scripts, ensure the
market_idis valid and corresponds to an existing market. If this ID is for example purposes, adding a comment for clarification would be helpful.- Adding error handling for the
await client.fetch_chain_full_spot_marketcall would enhance the script's reliability by addressing potential issues such as network errors or invalid market IDs.examples/chain_client/exchange/query/27_DerivativeMarkets.py (1)
- 1-22: - The script
27_DerivativeMarkets.pyis well-structured and demonstrates how to query multiple derivative markets based on specific criteria (e.g., status and market IDs) using theAsyncClient.
- Ensure the
market_idsarray contains valid market IDs. If these IDs are placeholders, it would be helpful to add a comment indicating that users should replace them with actual market IDs.- Adding error handling for the
await client.fetch_chain_derivative_marketscall would enhance the script's reliability by addressing potential issues such as network errors or invalid parameters.examples/chain_client/exchange/query/12_FullSpotMarkets.py (1)
- 1-23: - The script
12_FullSpotMarkets.pyeffectively demonstrates querying detailed information about multiple spot markets, including mid-price and top of the book (TOB), based on specific criteria using theAsyncClient.
- As with previous scripts, ensure the
market_idsarray contains valid market IDs. If these IDs are placeholders, adding a comment for clarification would be beneficial.- Adding error handling for the
await client.fetch_chain_full_spot_marketscall would improve the script's robustness by addressing potential issues such as network errors or invalid parameters.examples/chain_client/authz/query/1_Grants.py (1)
- 1-11: - The update to
1_Grants.pyto use environment variables forgranterandgranteepublic addresses enhances security by avoiding hardcoded values. This change aligns with best practices for sensitive information management.
- Ensure that the
.envfile or the environment variables are correctly set up with valid public addresses before running the script. It might be helpful to include a sample.envfile or documentation comments in the script to guide users on setting up these environment variables.- Consider adding error handling for scenarios where environment variables are not set or invalid, to provide clear feedback to the user.
examples/chain_client/distribution/query/4_ValidatorSlashes.py (1)
- 1-20: - The script
4_ValidatorSlashes.pyis well-structured and demonstrates how to query validator slashes using theAsyncClient. It correctly initializes the client and uses pagination to limit the number of results.
- Ensure the
validator_addressis valid and corresponds to an existing validator. If this address is a placeholder for demonstration purposes, adding a comment for clarification would be helpful.- Adding error handling for the
await client.fetch_validator_slashescall would enhance the script's reliability by addressing potential issues such as invalid addresses or network errors.examples/chain_client/exchange/query/22_DerivativeOrderbook.py (1)
- 1-25: - The script
22_DerivativeOrderbook.pyeffectively demonstrates querying the derivative order book for a specific market using theAsyncClient. It correctly initializes the client and uses pagination to limit the number of results.
- As with previous scripts, ensure the
market_idis valid and corresponds to an existing market. If this ID is for example purposes, adding a comment for clarification would be beneficial.- Adding error handling for the
await client.fetch_chain_derivative_orderbookcall would improve the script's robustness by addressing potential issues such as network errors or invalid market IDs.examples/chain_client/exchange/query/14_SpotOrderbook.py (1)
- 1-26: - The script is well-structured and follows good practices for asynchronous programming in Python.
- The use of
PaginationOptionwith a limit of 2 is a good practice for managing large datasets and preventing performance issues.- Hardcoding the
market_idandorder_sidein the script limits its flexibility. Consider making these parameters configurable through command-line arguments or environment variables to enhance the script's usability in different scenarios.- Ensure that the
market_idused in the script is valid and corresponds to an existing market on the Injective Protocol.examples/chain_client/exchange/query/41_TradeRewardCampaign.py (1)
- 1-32: - The use of
dotenvfor loading environment variables is a good practice for managing sensitive information, such as private keys, securely.
- It's important to validate the existence and correctness of the
INJECTIVE_PRIVATE_KEYenvironment variable before proceeding with its use. Consider adding error handling to provide clear feedback if the environment variable is not set or invalid.- The script demonstrates good practices in asynchronous programming and secure handling of private keys by loading them from environment variables instead of hardcoding them in the script.
examples/chain_client/exchange/query/52_MarketVolatility.py (1)
- 1-30: - The script is well-structured and follows good practices for asynchronous programming in Python.
- Hardcoding the
market_id,trade_grouping_sec,max_age,include_raw_history, andinclude_metadatain the script limits its flexibility. Consider making these parameters configurable through command-line arguments or environment variables to enhance the script's usability in different scenarios.- Ensure that the
market_idused in the script is valid and corresponds to an existing market on the Injective Protocol.examples/chain_client/exchange/query/39_TradeRewardPoints.py (1)
- 1-34: - The use of
dotenvfor loading environment variables is a good practice for managing sensitive information, such as private keys, securely.
- It's important to validate the existence and correctness of the
INJECTIVE_PRIVATE_KEYenvironment variable before proceeding with its use. Consider adding error handling to provide clear feedback if the environment variable is not set or invalid.- The script demonstrates good practices in asynchronous programming and secure handling of private keys by loading them from environment variables instead of hardcoding them in the script.
examples/chain_client/exchange/query/40_PendingTradeRewardPoints.py (1)
- 1-34: - The use of
dotenvfor loading environment variables is a good practice for managing sensitive information, such as private keys, securely.
- It's important to validate the existence and correctness of the
INJECTIVE_PRIVATE_KEYenvironment variable before proceeding with its use. Consider adding error handling to provide clear feedback if the environment variable is not set or invalid.- The script demonstrates good practices in asynchronous programming and secure handling of private keys by loading them from environment variables instead of hardcoding them in the script.
examples/chain_client/exchange/query/50_IsOptedOutOfRewards.py (1)
- 1-34: - The use of
dotenvfor loading environment variables is a good practice for managing sensitive information, such as private keys, securely.
- It's important to validate the existence and correctness of the
INJECTIVE_PRIVATE_KEYenvironment variable before proceeding with its use. Consider adding error handling to provide clear feedback if the environment variable is not set or invalid.- The script demonstrates good practices in asynchronous programming and secure handling of private keys by loading them from environment variables instead of hardcoding them in the script.
examples/chain_client/exchange/query/42_FeeDiscountAccountInfo.py (1)
- 1-34: - The use of
dotenvfor loading environment variables is a good practice for managing sensitive information, such as private keys, securely.
- It's important to validate the existence and correctness of the
INJECTIVE_PRIVATE_KEYenvironment variable before proceeding with its use. Consider adding error handling to provide clear feedback if the environment variable is not set or invalid.- The script demonstrates good practices in asynchronous programming and secure handling of private keys by loading them from environment variables instead of hardcoding them in the script.
examples/chain_client/exchange/query/5_AggregateVolumes.py (1)
- 1-34: - The use of
dotenvfor loading environment variables is a good practice for managing sensitive information, such as private keys, securely.
- It's important to validate the existence and correctness of the
INJECTIVE_PRIVATE_KEYenvironment variable before proceeding with its use. Consider adding error handling to provide clear feedback if the environment variable is not set or invalid.- The script demonstrates good practices in asynchronous programming and secure handling of private keys by loading them from environment variables instead of hardcoding them in the script.
examples/chain_client/exchange/query/1_SubaccountDeposits.py (1)
- 1-34: - The use of
dotenvfor loading environment variables is a good practice for managing sensitive information, such as private keys, securely.
- It's important to validate the existence and correctness of the
INJECTIVE_PRIVATE_KEYenvironment variable before proceeding with its use. Consider adding error handling to provide clear feedback if the environment variable is not set or invalid.- The script demonstrates good practices in asynchronous programming and secure handling of private keys by loading them from environment variables instead of hardcoding them in the script.
examples/chain_client/exchange/query/2_SubaccountDeposit.py (1)
- 1-34: - The use of
dotenvfor loading environment variables is a good practice for managing sensitive information, such as private keys, securely.
- It's important to validate the existence and correctness of the
INJECTIVE_PRIVATE_KEYenvironment variable before proceeding with its use. Consider adding error handling to provide clear feedback if the environment variable is not set or invalid.- The script demonstrates good practices in asynchronous programming and secure handling of private keys by loading them from environment variables instead of hardcoding them in the script.
examples/chain_client/exchange/query/30_SubaccountTradeNonce.py (3)
- 12-12: Loading environment variables at the start of the script is a good practice for managing sensitive information like private keys. This change enhances security by avoiding hard-coded credentials.
- 22-22: Converting the private key from hex to a
PrivateKeyobject is a secure way to handle sensitive information. Ensure that the environment variableINJECTIVE_PRIVATE_KEYis properly set in all deployment environments.- 29-31: Fetching the subaccount trade nonce is a critical operation for ensuring that transactions are processed in the correct order. This change appears to be correctly implemented.
examples/chain_client/exchange/query/38_SubaccountOrderMetadata.py (1)
- 29-31: Querying for subaccount order metadata is essential for tracking and managing orders. This functionality is correctly implemented, following the same secure practices as seen in the previous file.
examples/chain_client/exchange/query/32_SubaccountPositions.py (1)
- 29-31: Fetching subaccount positions is crucial for understanding the current state of an account's investments. The implementation here is consistent with best practices observed in previous files.
examples/chain_client/exchange/query/4_AggregateVolume.py (1)
- 28-32: The script fetches aggregate volume twice, once using the account address and then using the subaccount ID. This demonstrates flexibility in querying based on different identifiers. Ensure that both calls are necessary for the intended use case to avoid redundant network requests.
examples/chain_client/exchange/query/16_AccountAddressSpotOrders.py (1)
- 27-30: Querying spot orders by account address and market ID is a key operation. However, the market ID is hardcoded, which might limit the script's flexibility. Consider making the market ID a configurable parameter or environment variable for greater versatility.
examples/chain_client/exchange/query/24_AccountAddressDerivativeOrders.py (1)
- 27-30: Fetching derivative orders by account address and market ID is implemented correctly. As with the spot orders script, consider enhancing flexibility by not hardcoding the market ID.
examples/chain_client/exchange/query/18_SubaccountOrders.py (1)
- 29-31: Querying subaccount orders with a specific market ID is a crucial functionality. The implementation is consistent with best practices, but again, consider making the market ID configurable for enhanced script flexibility.
examples/chain_client/exchange/query/15_TraderSpotOrders.py (1)
- 29-31: Fetching trader spot orders by market ID and subaccount ID is well-implemented. As with other scripts, the hardcoded market ID could be made configurable to improve the script's usability in different scenarios.
examples/chain_client/exchange/query/23_TraderDerivativeOrders.py (1)
- 29-31: The script correctly implements fetching trader derivative orders. The hardcoded market ID issue is consistent across similar scripts; consider making it configurable for better flexibility.
examples/chain_client/exchange/query/19_TraderSpotTransientOrders.py (1)
- 29-31: Querying for trader spot transient orders is a unique functionality that complements the suite of query scripts. The implementation is correct, but the hardcoded market ID should be addressed as previously mentioned.
examples/chain_client/exchange/query/54_TraderDerivativeConditionalOrders.py (2)
- 1-4: The addition of
dotenvfor loading environment variables is a positive change for security, as it moves away from hardcoding sensitive information like private keys. Ensure that the.envfile is properly secured and not included in version control.- 29-32: Querying trader derivative conditional orders with a hardcoded
market_idlimits the script's flexibility. Consider makingmarket_ida parameter or an environment variable to enhance the script's usability across different markets.examples/chain_client/exchange/query/33_SubaccountPositionInMarket.py (2)
- 1-4: The use of
dotenvfor loading environment variables is consistent across the example scripts, which is good for maintaining a uniform approach to handling sensitive information like private keys.- 29-31: Similar to the previous file, consider enhancing the script's flexibility by making
market_idconfigurable through parameters or environment variables. This would allow the script to be more versatile across different markets.examples/chain_client/exchange/query/26_TraderDerivativeTransientOrders.py (2)
- 1-4: The consistent use of
dotenvfor loading environment variables across example scripts is a good practice, ensuring uniform handling of sensitive information like private keys.- 29-31: Encourage making
market_idconfigurable to enhance the script's usability across different markets. This aligns with the PR's objectives of improving flexibility and functionality.examples/chain_client/exchange/query/34_SubaccountEffectivePositionInMarket.py (2)
- 1-4: The use of
dotenvfor loading environment variables continues to be a positive and consistent change across the example scripts, enhancing security by avoiding hardcoded sensitive information.- 29-31: Encourage making
market_idconfigurable through parameters or environment variables to improve the script's flexibility and usability across different markets.examples/chain_client/tokenfactory/1_CreateDenom.py (1)
- 2-4: The addition of
osanddotenvimports for loading environment variables is a significant improvement in handling sensitive information securely by moving away from hardcoded private keys.examples/chain_client/exchange/query/17_SpotOrdersByHashes.py (2)
- 1-4: The consistent use of
dotenvfor loading environment variables across example scripts is a good practice, ensuring uniform handling of sensitive information like private keys.- 29-32: Encourage making
market_idandorder_hashesconfigurable through parameters or environment variables to improve the script's flexibility and usability across different markets and orders.examples/chain_client/exchange/query/25_DerivativeOrdersByHashes.py (2)
- 1-4: The use of
dotenvfor loading environment variables continues to be a positive and consistent change across the example scripts, enhancing security by avoiding hardcoded sensitive information.- 29-32: Encourage making
market_idandorder_hashesconfigurable through parameters or environment variables to improve the script's flexibility and usability across different markets and orders.examples/chain_client/tokenfactory/3_MsgBurn.py (2)
- 2-4: The addition of
osanddotenvimports for loading environment variables is a significant improvement in handling sensitive information securely by moving away from hardcoded private keys.- 29-29: The change to use
composer.coinfor creating theamountis a good practice, as it likely aligns with updated library conventions or best practices. Ensure that this change is consistently applied across all relevant scripts.examples/chain_client/distribution/1_SetWithdrawAddress.py (1)
- 1-6: The use of
dotenvto load environment variables andosto fetch the private key (INJECTIVE_PRIVATE_KEY) from the environment is a good practice for enhancing security by avoiding hardcoded sensitive information.examples/chain_client/distribution/3_WithdrawValidatorCommission.py (1)
- 1-6: The use of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_PRIVATE_KEY) is correctly implemented, enhancing security by avoiding hardcoded sensitive information.examples/chain_client/distribution/4_FundCommunityPool.py (1)
- 1-6: The introduction of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_PRIVATE_KEY) is correctly implemented. Additionally, the use ofDecimalfor precise calculations is a good practice for financial transactions.examples/chain_client/distribution/2_WithdrawDelegatorReward.py (1)
- 1-6: The use of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_PRIVATE_KEY) is correctly implemented, enhancing security by avoiding hardcoded sensitive information.examples/SendToInjective.py (2)
- 1-5: The introduction of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_PRIVATE_KEY) is correctly implemented, enhancing security by avoiding hardcoded sensitive information.- 12-13: Loading the private key from environment variables is a significant improvement in terms of security. This change ensures that sensitive information is not hardcoded into the script.
examples/chain_client/tokenfactory/5_MsgSetDenomMetadata.py (2)
- 1-4: The use of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_PRIVATE_KEY) is correctly implemented, enhancing security by avoiding hardcoded sensitive information.- 13-14: Loading the private key from environment variables is a significant improvement in terms of security. This change ensures that sensitive information is not hardcoded into the script.
examples/chain_client/exchange/3_MsgInstantSpotMarketLaunch.py (1)
- 1-6: The use of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_PRIVATE_KEY) is correctly implemented, enhancing security by avoiding hardcoded sensitive information.examples/chain_client/6_MessageBroadcasterWithGranteeAccountWithoutSimulation.py (1)
- 1-6: The introduction of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_GRANTEE_PRIVATE_KEY) and public address (INJECTIVE_GRANTER_PUBLIC_ADDRESS) is correctly implemented, enhancing security by avoiding hardcoded sensitive information.examples/chain_client/4_MessageBroadcasterWithGranteeAccount.py (1)
- 1-6: The use of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_GRANTEE_PRIVATE_KEY) and public address (INJECTIVE_GRANTER_PUBLIC_ADDRESS) is correctly implemented, enhancing security by avoiding hardcoded sensitive information.examples/chain_client/exchange/13_MsgInstantBinaryOptionsMarketLaunch.py (1)
- 1-6: The use of
dotenvfor loading environment variables andosfor fetching the private key (INJECTIVE_PRIVATE_KEY) is correctly implemented, enhancing security by avoiding hardcoded sensitive information.examples/chain_client/exchange/4_MsgInstantPerpetualMarketLaunch.py (1)
- 1-61: - The script correctly imports necessary modules, loads environment variables using
dotenv, and utilizesDecimalfor precise financial calculations. This enhances security by avoiding hardcoded private keys and improves accuracy in financial computations.
- Ensure that the environment variable
INJECTIVE_PRIVATE_KEYis securely managed and not exposed in any logs or error messages.- Consider adding error handling for
os.getenv("INJECTIVE_PRIVATE_KEY")to gracefully handle cases where the environment variable is not set.examples/chain_client/exchange/5_MsgInstantExpiryFuturesMarketLaunch.py (1)
- 1-62: - The script for launching an instant expiry futures market correctly uses environment variables and
Decimalfor precise calculations, following best practices for security and accuracy.
- Confirm that the
INJECTIVE_PRIVATE_KEYenvironment variable is handled securely throughout the application.- Suggest adding error handling for missing or invalid environment variables to improve the script's robustness.
examples/chain_client/5_MessageBroadcasterWithoutSimulation.py (1)
- 35-56: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-59]
- The script for broadcasting messages without simulation has been updated to use
Decimalfor financial values and string literals for order types, which enhances clarity and precision.- Ensure that the environment variable
INJECTIVE_PRIVATE_KEYis securely managed and not exposed in any logs or error messages.- Recommend adding error handling for the retrieval of the environment variable to gracefully handle cases where it might not be set.
examples/chain_client/3_MessageBroadcaster.py (1)
- 35-56: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-59]
- The script for message broadcasting with simulation correctly uses
Decimalfor financial values and string literals for order types, aligning with best practices for precision and clarity.- Confirm that the
INJECTIVE_PRIVATE_KEYenvironment variable is handled securely throughout the application.- Suggest adding error handling for missing or invalid environment variables to improve the script's robustness.
tests/test_orderhash.py (1)
- 24-44: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-41]
- The updates to the test file for order hash computation correctly use
Decimalfor financial values, enhancing the precision and reliability of the tests.- Consider adding more test cases to cover edge cases and potential error scenarios, ensuring comprehensive test coverage.
pyproject.toml (1)
- 1-6: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-54]
- The update to the project version and the addition of
python-dotenvas a dependency inpyproject.tomlare correctly implemented, aligning with the PR's objectives to enhance security and flexibility.- Ensure that all dependencies are kept up to date and that any new dependencies are evaluated for security and compatibility with the project.
examples/chain_client/exchange/21_MsgRewardsOptOut.py (1)
- 24-36: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-59]
- The script for opting out of rewards correctly uses environment variables for private keys and follows best practices for secure and precise transactions.
- Confirm that the
INJECTIVE_PRIVATE_KEYenvironment variable is handled securely throughout the application.- Recommend adding error handling for missing or invalid environment variables to improve the script's robustness.
examples/chain_client/auction/1_MsgBid.py (1)
- 12-20: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-59]
- The script for bidding in auctions correctly uses environment variables for private keys and follows best practices for secure and precise transactions.
- Ensure that the
INJECTIVE_PRIVATE_KEYenvironment variable is securely managed and not exposed in any logs or error messages.- Suggest adding error handling for missing or invalid environment variables to improve the script's robustness.
examples/chain_client/exchange/2_MsgWithdraw.py (1)
- 24-37: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-60]
- The script for withdrawing funds correctly uses environment variables for private keys and follows best practices for secure and precise transactions.
- Confirm that the
INJECTIVE_PRIVATE_KEYenvironment variable is handled securely throughout the application.- Recommend adding error handling for missing or invalid environment variables to improve the script's robustness.
examples/chain_client/bank/1_MsgSend.py (1)
- 12-20: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-64]
- The script for sending funds correctly uses environment variables for private keys and follows best practices for secure and precise transactions.
- Ensure that the
INJECTIVE_PRIVATE_KEYenvironment variable is securely managed and not exposed in any logs or error messages.- Suggest adding error handling for missing or invalid environment variables to improve the script's robustness.
examples/chain_client/exchange/1_MsgDeposit.py (6)
- 2-4: Importing
osanddotenvmodules and loading environment variables usingdotenv.load_dotenv()are good practices for enhancing security by avoiding hardcoded sensitive information like private keys. This change aligns with the PR's objective to improve security and flexibility.- 15-17: Successfully loading environment variables and retrieving the private key using
os.getenv("INJECTIVE_PRIVATE_KEY")is a secure way to handle sensitive information. Ensure that the environment variableINJECTIVE_PRIVATE_KEYis properly set in the deployment environment to avoid runtime errors.- 19-19: Switching to
Network.testnet()for selecting the network is a straightforward change. It's important to ensure that this aligns with the intended use case and that any necessary adjustments are made for different environments (e.g., mainnet).- 27-27: Converting the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correct and secure, assuming the private key is properly managed and stored.- 34-36: The update to the
msg_depositmethod call, including the dynamic setting of the sender, subaccount ID, amount, and denom, is correctly implemented. It's crucial to validate the input values, especially the amount and denom, to prevent unintended transactions.- 62-62: The change to use
composer.coinfor creating a coin object with dynamic gas price and limit calculation is appropriate. This approach ensures that transaction fees are calculated based on the actual gas used, plus a buffer, enhancing efficiency and preventing overpayment.examples/chain_client/oracle/1_MsgRelayPriceFeedPrice.py (4)
- 2-4: The addition of
osanddotenvmodules and the use ofdotenv.load_dotenv()to load environment variables are consistent with best practices for handling sensitive information securely. This approach is crucial for maintaining the security of the private key.- 15-17: Retrieving the private key from an environment variable using
os.getenv("INJECTIVE_PRIVATE_KEY")is a secure and flexible method. It's important to ensure the environment variable is set up correctly in the deployment environment.- 27-27: The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correctly implemented. This ensures that the private key is handled securely throughout the script.- 64-64: Updating the method call to
composer.coinfor fee calculation with dynamic gas price and limit is appropriate. This change ensures that fees are calculated accurately based on the actual gas used, which is a good practice for efficiency and cost management.examples/chain_client/staking/1_MsgDelegate.py (4)
- 2-4: The addition of
osanddotenvmodules and the use ofdotenv.load_dotenv()to load environment variables are consistent with best practices for handling sensitive information securely. This approach is crucial for maintaining the security of the private key.- 15-17: Retrieving the private key from an environment variable using
os.getenv("INJECTIVE_PRIVATE_KEY")is a secure and flexible method. It's important to ensure the environment variable is set up correctly in the deployment environment.- 27-27: The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correctly implemented. This ensures that the private key is handled securely throughout the script.- 64-64: Updating the method call to
composer.coinfor fee calculation with dynamic gas price and limit is appropriate. This change ensures that fees are calculated accurately based on the actual gas used, which is a good practice for efficiency and cost management.examples/chain_client/insurance/2_MsgUnderwrite.py (4)
- 2-4: The addition of
osanddotenvmodules and the use ofdotenv.load_dotenv()to load environment variables are consistent with best practices for handling sensitive information securely. This approach is crucial for maintaining the security of the private key.- 15-17: Retrieving the private key from an environment variable using
os.getenv("INJECTIVE_PRIVATE_KEY")is a secure and flexible method. It's important to ensure the environment variable is set up correctly in the deployment environment.- 28-28: The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correctly implemented. This ensures that the private key is handled securely throughout the script.- 64-64: Updating the method call to
composer.coinfor fee calculation with dynamic gas price and limit is appropriate. This change ensures that fees are calculated accurately based on the actual gas used, which is a good practice for efficiency and cost management.examples/chain_client/authz/3_MsgRevoke.py (5)
- 2-4: The addition of
osanddotenvmodules and the use ofdotenv.load_dotenv()to load environment variables are consistent with best practices for handling sensitive information securely. This approach is crucial for maintaining the security of the private key.- 15-18: Retrieving the private key and grantee public address from environment variables using
os.getenv()is a secure and flexible method. It's important to ensure the environment variables are set up correctly in the deployment environment. This approach enhances the script's flexibility by allowing dynamic configuration.- 28-28: The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correctly implemented. This ensures that the private key is handled securely throughout the script.- 35-36: The update to the
MsgRevokeinstantiation with dynamicgranterandgranteevalues is correctly implemented. It's crucial to validate the input values, especially thegranteepublic address, to prevent unintended revocations.- 64-64: Updating the method call to
composer.coinfor fee calculation with dynamic gas price and limit is appropriate. This change ensures that fees are calculated accurately based on the actual gas used, which is a good practice for efficiency and cost management.examples/chain_client/insurance/3_MsgRequestRedemption.py (4)
- 2-4: The addition of
osanddotenvmodules and the use ofdotenv.load_dotenv()to load environment variables are consistent with best practices for handling sensitive information securely. This approach is crucial for maintaining the security of the private key.- 15-17: Retrieving the private key from an environment variable using
os.getenv("INJECTIVE_PRIVATE_KEY")is a secure and flexible method. It's important to ensure the environment variable is set up correctly in the deployment environment.- 28-28: The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correctly implemented. This ensures that the private key is handled securely throughout the script.- 64-64: Updating the method call to
composer.coinfor fee calculation with dynamic gas price and limit is appropriate. This change ensures that fees are calculated accurately based on the actual gas used, which is a good practice for efficiency and cost management.examples/chain_client/insurance/1_MsgCreateInsuranceFund.py (4)
- 2-4: The addition of
osanddotenvmodules and the use ofdotenv.load_dotenv()to load environment variables are consistent with best practices for handling sensitive information securely. This approach is crucial for maintaining the security of the private key.- 15-17: Retrieving the private key from an environment variable using
os.getenv("INJECTIVE_PRIVATE_KEY")is a secure and flexible method. It's important to ensure the environment variable is set up correctly in the deployment environment.- 28-28: The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correctly implemented. This ensures that the private key is handled securely throughout the script.- 68-68: Updating the method call to
composer.coinfor fee calculation with dynamic gas price and limit is appropriate. This change ensures that fees are calculated accurately based on the actual gas used, which is a good practice for efficiency and cost management.examples/chain_client/exchange/17_MsgSubaccountTransfer.py (3)
- 2-5: The addition of
os,dotenv, andDecimalfrom thedecimalmodule, along with the use ofdotenv.load_dotenv()to load environment variables, are consistent with best practices for handling sensitive information securely and performing precise calculations. This approach is crucial for maintaining the security of the private key and ensuring accurate financial transactions.- 16-18: Retrieving the private key from an environment variable using
os.getenv("INJECTIVE_PRIVATE_KEY")is a secure and flexible method. It's important to ensure the environment variable is set up correctly in the deployment environment. Additionally, the use ofDecimalfor the amount ensures precise financial calculations, which is critical in financial applications.- 28-28: The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correctly implemented. This ensures that the private key is handled securely throughout the script.examples/chain_client/exchange/12_MsgCancelDerivativeOrder.py (5)
- 2-4: - The addition of
osanddotenvimports is appropriate for loading environment variables, enhancing the script's security by avoiding hardcoded sensitive information.- 15-16: - Using
dotenv.load_dotenv()to load environment variables and fetching the private key usingos.getenv("INJECTIVE_PRIVATE_KEY")is a secure practice, ensuring that sensitive information is not hardcoded.- 27-27: - The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correct and ensures that the private key is properly handled.- 38-38: - The change from
composer.MsgCancelDerivativeOrdertocomposer.msg_cancel_derivative_orderfollows Python's naming conventions and improves code readability.- 66-66: - The modification from
composer.Cointocomposer.coinfor gas fee calculation aligns with Python's naming conventions and ensures consistency across the project.examples/chain_client/exchange/18_MsgExternalTransfer.py (5)
- 2-5: - Importing
os,Decimal, anddotenvmodules is correctly done to support environment variable loading and precise calculations.- 16-17: - Loading environment variables and retrieving the private key securely using
dotenv.load_dotenv()andos.getenv()is a good practice.- 28-28: - Correctly converting the private key from hexadecimal format ensures secure and proper handling of sensitive information.
- 36-40: - The update to
msg_external_transferfor message creation and the use ofDecimalfor the amount ensure accurate financial transactions and align with best practices.- 68-68: - Adjusting the gas fee calculation to use
composer.coinis consistent with the project's coding standards and improves readability.examples/chain_client/exchange/20_MsgIncreasePositionMargin.py (5)
- 2-5: - The imports of
os,Decimal, anddotenvare correctly implemented to support the script's functionality and security.- 16-17: - Securely loading the private key from environment variables using
dotenv.load_dotenv()andos.getenv()is a best practice for handling sensitive information.- 28-28: - The conversion of the private key from a hexadecimal string to a
PrivateKeyobject is correctly implemented, ensuring secure handling of the key.- 38-43: - Updating the
msg_increase_position_marginfunction call and usingDecimalfor the amount parameter ensures precise financial calculations.- 70-70: - The modification to use
composer.coinfor gas fee calculation aligns with the project's coding standards and improves code readability.examples/chain_client/wasmx/1_MsgExecuteContractCompat.py (4)
- 3-5: - The addition of
osanddotenvimports is correctly done to support environment variable loading, enhancing the script's security.- 16-17: - Securely loading the private key from environment variables using
dotenv.load_dotenv()andos.getenv()is a good practice.- 27-27: - The conversion of the private key from hexadecimal to a
PrivateKeyobject is correctly implemented, ensuring secure handling of the key.- 71-71: - The change to use
composer.coinfor gas fee calculation is consistent with the project's coding standards and improves code readability.examples/chain_client/peggy/1_MsgSendToEth.py (4)
- 2-4: - Importing
osanddotenvis correctly done to support environment variable loading, enhancing the script's security by avoiding hardcoded sensitive information.- 16-17: - Using
dotenv.load_dotenv()to load environment variables and fetching the private key usingos.getenv("INJECTIVE_PRIVATE_KEY")is a secure practice.- 28-28: - The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correct and ensures that the private key is properly handled.- 73-73: - The modification from
composer.Cointocomposer.coinfor gas fee calculation aligns with Python's naming conventions and ensures consistency across the project.examples/chain_client/exchange/16_MsgCancelBinaryOptionsOrder.py (5)
- 2-4: - The addition of
osanddotenvimports is appropriate for loading environment variables, enhancing the script's security by avoiding hardcoded sensitive information.- 15-16: - Using
dotenv.load_dotenv()to load environment variables and fetching the private key usingos.getenv("INJECTIVE_PRIVATE_KEY")is a secure practice.- 27-27: - The conversion of the private key from hexadecimal to a
PrivateKeyobject usingPrivateKey.from_hex(configured_private_key)is correct and ensures that the private key is properly handled.- 38-38: - The change from a previous method call to
composer.msg_cancel_binary_options_orderfollows Python's naming conventions and improves code readability.- 69-69: - The modification from
composer.Cointocomposer.coinfor gas fee calculation aligns with Python's naming conventions and ensures consistency across the project.examples/chain_client/wasm/1_MsgExecuteContract.py (5)
- 2-4: - Importing
osanddotenvis correctly done to support environment variable loading, enhancing the script's security by avoiding hardcoded sensitive information.- 15-16: - Securely loading the private key from environment variables using
dotenv.load_dotenv()andos.getenv()is a good practice.- 28-28: - The conversion of the private key from hexadecimal to a
PrivateKeyobject is correctly implemented, ensuring secure handling of the key.- 36-41: - The update to use
composer.coinfor creating coin amounts in the funds array is consistent with the project's coding standards and improves code readability.- 74-74: - The change to use
composer.coinfor gas fee calculation is consistent with the project's coding standards and improves code readability.examples/chain_client/exchange/22_MsgAdminUpdateBinaryOptionsMarket.py (5)
- 2-5: - Importing
os,Decimal, anddotenvmodules is correctly done to support environment variable loading and precise calculations.- 16-17: - Loading environment variables and retrieving the private key securely using
dotenv.load_dotenv()andos.getenv()is a good practice for handling sensitive information.- 28-28: - Correctly converting the private key from hexadecimal format ensures secure and proper handling of sensitive information.
- 41-41: - The update to
msg_admin_update_binary_options_marketfor message creation and the use ofDecimalfor the settlement price ensure accurate financial transactions and align with best practices.- 78-78: - Adjusting the gas fee calculation to use
composer.coinis consistent with the project's coding standards and improves readability.examples/chain_client/exchange/7_MsgCreateSpotMarketOrder.py (5)
- 2-6: - Importing
os,Decimal, anddotenvmodules is correctly done to support environment variable loading and precise calculations.- 17-18: - Loading environment variables and retrieving the private key securely using
dotenv.load_dotenv()andos.getenv()is a good practice for handling sensitive information.- 29-29: - Correctly converting the private key from hexadecimal format ensures secure and proper handling of sensitive information.
- 40-47: - The update to
composer.msg_create_spot_market_orderfor message creation and the use ofDecimalfor price and quantity values ensure accurate financial transactions and align with best practices.- 79-79: - Adjusting the gas fee calculation to use
composer.coinis consistent with the project's coding standards and improves readability.tests/client/chain/grpc/configurable_distribution_query_servicer.py (1)
- 1-69: - The implementation of
ConfigurableDistributionQueryServiceris well-structured, using deques to simulate responses for distribution-related queries. This approach allows for flexible and controlled testing of the gRPC servicer methods.tests/client/chain/grpc/test_chain_grpc_authz_api.py (1)
- 10-10: The correction of the typo in the import statement from
configurable_autz_query_servicertoconfigurable_authz_query_serviceris crucial for ensuring the correctness of the test suite. This change allows the test suite to correctly import and utilize theConfigurableAuthZQueryServicerclass, which is essential for testing theChainGrpcAuthZApifunctionalities.tests/core/test_message_based_transaction_fee_calculator.py (2)
- 120-127: The changes made to use
Decimalforpriceandquantityfields, and the replacement of boolean flags with anorder_typefield set to "BUY", significantly improve the precision of financial calculations and the clarity of the code. UsingDecimalis crucial for financial applications to avoid rounding errors, and theorder_typefield enhances readability and maintainability by clearly specifying the type of order.- 120-127: The refactoring of message creation in test functions, including the use of lowercase function names and adjustments in message parameters, enhances the consistency and readability of the codebase. This approach aligns with Python's naming conventions and improves the maintainability of the test suite by making the code more intuitive and easier to follow.
Also applies to: 150-157, 185-192
CHANGELOG.md (1)
- 5-9: The changelog entries for version 1.4.0 are clear and concise, effectively summarizing the significant additions and improvements made in this release. However, there's a minor typographical issue to address:
- The term "python-dotenv" is correctly spelled, but the static analysis tool suggested "python-dot env" as a replacement. This suggestion is incorrect, and the original spelling should be retained.
Overall, the changelog update for version 1.4.0 is well-documented and adheres to best practices for changelog entries.
examples/chain_client/1_LocalOrderHash.py (4)
- 2-6: The addition of
os,Decimal, anddotenvimports aligns with the PR's objectives to enhance security and flexibility by moving away from hardcoded private keys to environment variables and usingDecimalfor precise calculations. Ensure that these modules are used consistently throughout the script.- 17-18: Loading environment variables at the beginning of the
mainfunction is a good practice for managing sensitive information such as private keys. This change enhances security by not hardcoding sensitive data within the script.- 48-50: The use of
Decimalfor specifyingprice,quantity, andmarginensures precise calculations, which is crucial for financial transactions. Additionally, changing order types to strings ("BUY", "SELL", "BUY_PO", "SELL_PO") improves readability and maintainability of the code.Also applies to: 57-59, 69-73, 81-85, 177-179, 186-188, 198-202, 210-214
- 92-96: The adjustments in function calls to
composer.msg_batch_create_spot_limit_ordersandcomposer.msg_batch_create_derivative_limit_ordersreflect the new naming conventions and enhance the clarity of the code. It's important to verify that these changes are consistently applied across all relevant parts of the project to avoid any integration issues.Also applies to: 221-225
Verification successful
The search results indicate that the changes to the function names
composer.msg_batch_create_spot_limit_ordersandcomposer.msg_batch_create_derivative_limit_ordersare consistently applied across the project. This includes their usage in examples, tests, and within thepyinjectivemodule itself, with appropriate deprecation warnings and test cases in place to handle the transition. Therefore, the adjustments reflect the new naming conventions and enhance the clarity of the code as intended.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for old function names to ensure they've been updated everywhere. rg --type py 'msg_batch_create_spot_limit_orders|msg_batch_create_derivative_limit_orders'Length of output: 2400
pyinjective/denoms_devnet.ini (2)
- 167-170: The adjustments to
min_price_tick_size,min_display_price_tick_size,min_quantity_tick_size, andmin_display_quantity_tick_sizefor various trading pairs are crucial for reflecting accurate trading conditions on the devnet. It's important to ensure these values are consistent with the intended trading parameters and that similar adjustments are made across all relevant configurations.Also applies to: 176-179, 185-188, 194-197
- 317-319: Updates to peggy denominations and decimals for tokens like HDRO, KIRA, and QUNT are necessary for accurate representation and handling of these tokens within the system. Verify that these updates align with the latest token specifications and that all references to these tokens in the project are updated accordingly.
Also applies to: 325-327, 341-343
Verification successful
The script output confirms that references to the tokens HDRO, KIRA, and QUNT are consistently found across different .ini files (
denoms_testnet.ini,denoms_mainnet.ini, anddenoms_devnet.ini) within the project. This indicates that the updates to peggy denominations and decimals for these tokens are applied across various network configurations (testnet, mainnet, devnet), aligning with the necessity for accurate representation and handling within the system as mentioned in the review comment.However, verifying the alignment of these updates with the latest token specifications requires external data, which is beyond the scope of this verification process. Therefore, based on the provided context and the script output, the consistency of token references across the project's configuration files is confirmed.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for references to the updated tokens to ensure consistency. rg --type ini 'HDRO|KIRA|QUNT'Length of output: 60
Script:
#!/bin/bash # Search for references to the updated tokens to ensure consistency, specifically targeting .ini files. rg -g '*.ini' 'HDRO|KIRA|QUNT'Length of output: 973
pyinjective/core/broadcaster.py (1)
- 267-267: The conversion of method calls from
self._composer.Cointoself._composer.coinfor configuring gas fees aligns with Python's convention of using lowercase for method names. This change improves consistency and readability. Ensure that this naming convention is consistently applied throughout the project.Also applies to: 295-295
pyinjective/core/market.py (1)
- 172-181: The implementation of
margin_to_chain_formatin theBinaryOptionMarketclass correctly converts human-readable margin values to chain-formatted values, considering special denominations if provided. This addition follows the established pattern of similar conversion methods in the file, usingDecimalfor precise calculations and supporting optionalspecial_denomfor flexibility. The method is consistent with best practices for financial calculations.tests/client/chain/grpc/test_chain_grpc_distribution_api.py (3)
- 18-54: The test case
test_fetch_module_paramsis well-structured and effectively tests the functionality of fetching module params from the distribution API. It uses a fixture for the distribution servicer and mocks the API's stub to use this servicer, with clear assertions comparing the expected dictionary with the result from the API call.- 56-84: The test case
test_fetch_validator_distribution_infoeffectively tests the API's functionality to fetch validator distribution info. It follows a consistent structure and approach, effectively mocking the necessary responses and validating the API's functionality with clear assertions.- 86-110: The test case
test_fetch_validator_outstanding_rewardseffectively tests the API's functionality to fetch validator outstanding rewards. It follows a consistent pattern with well-structured mocks and clear assertions, demonstrating the effectiveness of the test.pyinjective/denoms_testnet.ini (3)
- 145-152: The configuration for
Testnet Spot TEST2/INJandTestnet Spot TEST2/USDTintroduces a significant change inmin_price_tick_sizeforTEST2/INJcompared to other configurations. This could potentially be an error or a very specific requirement. Please verify the correctness of themin_price_tick_sizeforTEST2/INJbeing set to100000000, which is significantly higher than typical values seen in other configurations.- 468-470: The addition of the
HDROtoken configuration introduces a new peggy_denom and specifies its decimals. It's important to ensure that the peggy_denom address and decimals are correctly configured to match the token's specifications on the blockchain. Any discrepancy here could lead to incorrect handling of token amounts in the application.- 492-498: The addition of
TEST1andTEST2tokens with their respective peggy_denom configurations is noted. It's crucial to verify that these tokens and their peggy_denom addresses are correctly set up in the blockchain environment the application interacts with. Misconfiguration could lead to issues with token transfers or balance queries.tests/core/test_gas_limit_estimator.py (16)
- 27-33: - The use of
Decimalforpriceandquantityincomposer.spot_orderis a good practice for financial calculations, ensuring precision.
- The introduction of
order_typeinstead of boolean flags likeis_buyimproves readability and flexibility.
- 44-44: - The method
msg_batch_create_spot_limit_orderscorrectly aggregates the orders. Ensure that thesenderparameter is properly validated upstream to prevent misuse.- 56-66: - The use of
composer.order_datafor canceling spot orders is correctly implemented. It's important to ensure thatorder_hashvalues are validated and sanitized to prevent any injection attacks.- 72-72: - The method
msg_batch_cancel_spot_ordersis correctly used for batch canceling spot orders. Similar to the creation of orders, ensure that thesenderparameter is validated.- 84-100: - The use of
Decimalforprice,quantity, andmarginincomposer.derivative_orderis correctly applied, ensuring accurate financial calculations.
- The distinction between
BUYandSELLorder types is clear and enhances the code's readability.
- 103-103: - The method
msg_batch_create_derivative_limit_ordersis used appropriately for creating derivative limit orders. As with other methods, ensure thesenderparameter is validated to prevent unauthorized use.- 115-125: - The use of
composer.order_datafor canceling derivative orders follows the same pattern as for spot orders. Ensure thatorder_hashvalues are properly validated to prevent any potential security issues.- 131-131: - The method
msg_batch_cancel_derivative_orderscorrectly implements the batch canceling of derivative orders. Validate thesenderparameter as a security measure.- 143-157: - The test case for updating orders to create spot orders demonstrates the flexibility of the system to handle various order types. The use of
Decimalfor precise calculations is consistent and appropriate.- 178-194: - The test case for updating orders to create derivative orders is well-implemented, showcasing the system's ability to handle complex order types with precision using
Decimal.- 233-249: - The test case for updating orders to create binary options orders is correctly implemented, using
Decimalfor financial calculations and clearly distinguishing betweenBUYandSELLorder types.- 271-281: - The test case for batch updating orders to cancel spot orders is implemented correctly. It's important to ensure that
order_hashvalues are validated to prevent any potential security issues.- 305-315: - The test case for batch updating orders to cancel derivative orders follows the established pattern and is correctly implemented. Validate
order_hashvalues for security.- 339-349: - The test case for batch updating orders to cancel binary options orders is correctly implemented. As with other order types, ensure that
order_hashvalues are validated.- 434-440: - The test case for executing a message within another message (
MsgExec) is correctly implemented, showcasing advanced use cases. Ensure that nested messages are validated and sanitized appropriately.- 502-509: - The method
msg_create_spot_limit_orderis used correctly for creating a spot limit order. The use ofDecimalforpriceandquantityensures precision in financial calculations.tests/core/test_market.py (2)
- 251-272: - The method
test_convert_margin_to_chain_format_with_fixed_denomcorrectly tests the conversion of margin values to chain format using a fixed denomination. This test ensures that margin values are accurately converted, taking into account the fixed denomination's specifics.- 274-285: - The method
test_convert_margin_to_chain_format_without_fixed_denomtests the conversion of margin values to chain format without a fixed denomination. This test verifies the flexibility of the conversion functionality to handle different market configurations.pyinjective/client/chain/grpc/chain_grpc_exchange_api.py (3)
- 13-16: The class initialization is well-implemented, correctly setting up the necessary components for making gRPC calls. It's good practice to separate the creation of the stub and the request assistant, as it enhances modularity and testability.
- 18-578: All async methods in the
ChainGrpcExchangeApiclass follow a consistent and clear pattern for making gRPC calls. This consistency is beneficial for maintainability and readability. It's also good to see the use of type hints for method return types, enhancing code clarity and developer experience.- 577-578: The
_execute_callhelper method is well-designed, abstracting the execution of gRPC calls and centralizing error handling and metadata management. This design choice simplifies the public method implementations and enhances code maintainability.pyinjective/denoms_mainnet.ini (19)
- 685-692: The addition of the
DOJO/INJspot trading pair with its corresponding tick sizes and quantities is noted. Ensure that these values have been validated against the current market requirements and Injective Protocol's standards for precision and minimum quantities.- 694-701: The addition of the
GYEN/USDTspot trading pair introduces a fiat-pegged stablecoin pair. It's crucial to verify the demand for this trading pair within the Injective Protocol ecosystem and ensure that the peggy_denom value for GYEN is correctly set up in the system to facilitate seamless transactions.- 703-710: The addition of the
USDCnb/USDTspot trading pair is observed. Given the naming convention, it appears to be a specific version or network bridge of USDC. Confirm that the peggy_denom and decimals forUSDCnbare correctly configured and that there's clear documentation for users regarding this specific token variant.- 713-719: The
ANDR/INJspot trading pair has been added with a significant minimum price tick size of 10,000,000 and a display tick size of 0.00001. This configuration suggests a high-value asset or a specific use case. Ensure that this configuration aligns with the asset's market characteristics and the platform's trading strategy.- 721-728: The addition of the
hINJ/INJspot trading pair is noted. Given the naming, this might represent a wrapped or staked version of INJ. Confirm that the community and stakeholders are aware of this new trading pair and that the necessary infrastructure (e.g., smart contracts for wrapping/unwrapping) is in place and has been audited for security.- 739-746: The addition of the
PHUC/INJspot trading pair with its specific tick sizes and quantities is observed. Given the unique naming, ensure that there's adequate information available about this asset, including its utility and how it integrates with the Injective Protocol ecosystem.- 748-755: The addition of the
QUNT/INJspot trading pair is noted. It's important to verify the demand for this trading pair within the Injective Protocol ecosystem and ensure that the peggy_denom value for QUNT is correctly set up in the system to facilitate seamless transactions.- 757-764: The addition of the
WHALE/INJspot trading pair introduces a potentially high-value asset pair. Confirm that the peggy_denom for WHALE is correctly configured and that there's clear documentation for users regarding this asset, including its origins and utility within the ecosystem.- 766-773: The addition of the
HDRO/INJspot trading pair is observed. Given the specific configuration, ensure that this trading pair aligns with the market demand and that the HDRO asset is well-documented within the Injective Protocol ecosystem.- 776-782: The addition of the
PYTH/INJspot trading pair with a significant minimum price tick size of 10,000,000 suggests a high-value or high-precision asset. Verify that this configuration aligns with PYTH's market characteristics and that there's clear communication to users about this trading pair.- 838-845: The addition of the
OSMO/USDT PERPderivative trading pair with specific tick sizes and quantities is noted. Ensure that these values have been validated against current market requirements and Injective Protocol's standards for precision and minimum quantities in derivative markets.- 857-863: The
BONK/USDT PERPderivative trading pair introduces a unique configuration with a minimum price tick size of 0.01 and a display tick size of 0.00000001. This configuration suggests a high-precision or high-volatility asset. Confirm that this aligns with BONK's market characteristics and the platform's trading strategy for derivatives.- 937-944: The addition of the
AVAX/USDT PERPderivative trading pair is observed. Given AVAX's prominence in the cryptocurrency market, ensure that the derivative contract specifications, including tick sizes and quantities, are aligned with market expectations and Injective Protocol's risk management practices.- 946-953: The addition of the
SUI/USDT PERPderivative trading pair introduces a newer asset to the derivatives market. Verify the demand for this trading pair within the Injective Protocol ecosystem and ensure that the contract specifications are clearly communicated to users.- 955-962: The
WIF/USDT PERPderivative trading pair is added with specific tick sizes and quantities. Given the unique naming, confirm that there's adequate information available about this asset, including its utility and how it integrates with the Injective Protocol's derivatives market.- 973-980: The addition of the
ARB/USDT PERPderivative trading pair is noted. Ensure that these values have been validated against current market requirements and Injective Protocol's standards for precision and minimum quantities in derivative markets, especially considering ARB's potential market dynamics.- 982-989: The
W/USDT PERPderivative trading pair introduces a potentially high-value asset pair. Confirm that the peggy_denom for W is correctly configured and that there's clear documentation for users regarding this asset, including its origins and utility within the derivatives market.- 991-998: The addition of the
LINK/USDT PERPderivative trading pair with specific tick sizes and quantities is observed. Given LINK's prominence in the cryptocurrency market, ensure that the derivative contract specifications are aligned with market expectations and Injective Protocol's risk management practices.- 1000-1007: The addition of the
DOGE/USDT PERPderivative trading pair introduces a popular meme coin to the derivatives market. Confirm that the contract specifications, including tick sizes and quantities, are clearly communicated to users and align with DOGE's market characteristics and volatility.tests/test_composer.py (31)
- 79-79: The use of a large literal number (
1_000_000) for theamountparameter intest_msg_mintis clear and improves readability. However, it's important to ensure that such large numbers are handled correctly in the context of the application, especially when dealing with financial transactions.- 178-208: In
test_msg_deposit, the conversion ofamountto a chain-formatted value usingexpected_amount = token.chain_formatted_value(human_readable_value=Decimal(amount))is a good practice for ensuring consistency in how amounts are represented and processed. It's crucial to verify that thechain_formatted_valuemethod accurately handles the conversion, especially with respect to rounding and precision.Verification successful
The implementation of
chain_formatted_valueinpyinjective/core/token.pycorrectly handles rounding and precision by using theDecimalclass for arithmetic operations and scaling thehuman_readable_valueby10^decimals. This approach is consistent with best practices for converting between human-readable and chain-formatted values in cryptocurrency applications. The review comment's concern about ensuring consistency in how amounts are represented and processed is addressed by this implementation.* 209-238: The test `test_msg_withdraw` follows a similar pattern to `test_msg_deposit`, including the conversion of amounts for consistency. It's equally important here to ensure that the conversion logic is robust and tested, especially given the financial implications of withdrawal operations.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify the implementation of chain_formatted_value to ensure it handles rounding and precision correctly. cat tests/test_composer.py | grep -A 10 "def chain_formatted_value"Length of output: 69
Script:
#!/bin/bash # Search for the implementation of chain_formatted_value across the entire codebase rg "def chain_formatted_value" --files-with-matchesLength of output: 79
Script:
#!/bin/bash # Display the implementation of chain_formatted_value from pyinjective/core/token.py cat pyinjective/core/token.py | grep -A 20 "def chain_formatted_value"Length of output: 219
Verification successful
The implementation of
chain_formatted_valueinpyinjective/core/token.pycorrectly converts human-readable values to the chain's format by adjusting for the token's decimal places. This method is appropriately used in thetest_msg_withdrawto ensure that withdrawal amounts are correctly formatted for blockchain transactions. The review comment's concern about the importance of robust conversion logic, especially for financial operations, is addressed by this implementation.* 240-279: In `test_msg_instant_spot_market_launch`, the calculation of `expected_min_price_tick_size` and `expected_min_quantity_tick_size` involves adjusting for token decimals and additional chain format decimals. This approach is commendable for its attention to detail in ensuring that tick sizes are accurately represented on-chain. It's important to validate these calculations against expected outcomes to prevent any unintended market behavior. * 281-342: The `test_msg_instant_perpetual_market_launch` method includes comprehensive testing of various market parameters, including fee rates and margin ratios, converted for chain compatibility. This thorough testing is crucial for ensuring that market launches behave as expected, particularly in terms of financial risk management. Continuous validation of these parameters against real-world scenarios is recommended.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Reuse the previous script to verify the implementation of chain_formatted_value for withdrawal amounts. cat tests/test_composer.py | grep -A 10 "def chain_formatted_value"Length of output: 69
Script:
#!/bin/bash # Search for the definition of chain_formatted_value across the entire codebase rg "def chain_formatted_value" --context 10Length of output: 662
Verification successful
The review comment regarding the
test_msg_instant_perpetual_market_launchmethod is justified. The method indeed includes comprehensive testing of various market parameters, such as fee rates and margin ratios, converted for chain compatibility. This testing is crucial for ensuring that market launches behave as expected, particularly in terms of financial risk management. The recommendation for continuous validation of these parameters against real-world scenarios is well-founded, emphasizing the importance of maintaining robustness under various market conditions.* 344-408: The `test_msg_instant_expiry_futures_market_launch` function tests the launching of an expiry futures market with various parameters, including oracle settings and fee rates. Given the complexity of futures markets, it's essential to ensure that all parameters are correctly set and that the market behaves as expected under various conditions. * 410-451: The `test_spot_order` function demonstrates the creation of a spot order with detailed assertions on the expected order structure. This level of detail is crucial for ensuring that orders are correctly formatted and processed by the system. It's recommended to also include negative test cases to ensure robust error handling.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Suggest manual review for validating market parameters in test_msg_instant_perpetual_market_launch. echo "Manual review recommended for validating market parameters in test_msg_instant_perpetual_market_launch."Length of output: 216
Consider adding negative test cases to ensure the system gracefully handles invalid or malformed orders.
- 453-497: In
test_derivative_order, similar to the spot order test, the creation and validation of a derivative order are thoroughly tested. Including tests for edge cases, such as orders with zero quantity or invalid market IDs, would further strengthen the test suite's coverage and robustness.Enhance the test suite by including edge cases and negative scenarios for derivative orders to ensure comprehensive coverage.
- 499-547: The
test_msg_create_spot_limit_ordermethod correctly tests the creation of a spot limit order, ensuring that all fields are properly set. It's important to verify that the system's order matching logic correctly interprets and executes these orders as intended, especially in edge cases.- 549-584: The
test_msg_batch_create_spot_limit_ordersfunction tests the batch creation of spot limit orders, an important feature for users who need to execute multiple orders efficiently. Ensuring that the batch processing logic maintains order integrity and correctly handles partial failures is critical.- 586-633: The
test_msg_create_spot_market_ordermethod tests the creation of a spot market order. It's crucial to ensure that market orders are executed according to current market conditions and that the test reflects realistic scenarios, including liquidity considerations.- 635-661: In
test_msg_cancel_spot_order, the cancellation of a spot order is tested. It's important to verify that the cancellation process correctly identifies and nullifies the specified order without affecting other orders, especially in high-frequency trading environments.- 663-688: The
test_msg_batch_cancel_spot_ordersfunction tests the batch cancellation of spot orders. This feature is critical for users needing to quickly adjust their positions. Ensuring that the batch cancellation process is atomic and either fully succeeds or reverts in case of failure is essential for maintaining market integrity.- 690-787: The
test_msg_batch_update_ordersmethod tests a complex scenario involving the creation and cancellation of multiple order types across different markets. This comprehensive test is crucial for ensuring that the system can handle complex order management operations. It's recommended to also test the resilience of this feature under high load or failure conditions.Consider stress testing the batch update orders feature to ensure its resilience and reliability under high load or partial failure conditions.
- 789-812: In
test_msg_privileged_execute_contract, the execution of a contract with privileged access is tested. Given the potential security implications, it's vital to ensure that only authorized entities can invoke this functionality and that all security checks are robust and comprehensive.- 814-863: The
test_msg_create_derivative_limit_orderfunction tests the creation of a derivative limit order, which is essential for derivative market participants. Ensuring that these orders are accurately represented and processed in the matching engine, especially under various market conditions, is crucial.- 866-901: In
test_msg_batch_create_derivative_limit_orders, the batch creation of derivative limit orders is tested. This functionality is important for traders managing large portfolios. Verifying that the system can efficiently process and match these orders in batch mode without performance degradation is essential.- 904-953: The
test_msg_create_derivative_market_ordermethod tests the creation of a derivative market order. It's important to ensure that these orders are executed with respect to current market liquidity and that slippage is handled appropriately. Testing against various liquidity scenarios would enhance the robustness of this test.Enhance testing of derivative market orders by including various liquidity scenarios to assess slippage handling and execution accuracy.
- 956-995: In
test_msg_cancel_derivative_order, the cancellation of a derivative order is tested. Ensuring that the cancellation logic correctly identifies the target order without impacting other market participants is crucial. Additionally, testing the system's ability to handle rapid order cancellations in volatile markets is recommended.Consider testing the derivative order cancellation feature under scenarios of high market volatility and rapid order submissions/cancellations to ensure system stability and correctness.
- 997-1021: The
test_msg_batch_cancel_derivative_ordersfunction tests the batch cancellation of derivative orders. Similar to spot order batch cancellations, verifying the atomicity and reliability of this process is essential, especially in fast-moving derivative markets where timing is critical.- 1023-1085: The
test_msg_instant_binary_options_market_launchmethod tests the launching of a binary options market with various parameters. Given the unique characteristics of binary options markets, ensuring that all parameters are correctly set and that the market behaves as expected under different scenarios is critical.- 1087-1136: In
test_msg_create_binary_options_limit_order, the creation of a binary options limit order is tested. This test is important for ensuring that binary options orders are correctly processed and matched. Including tests for scenarios where the market moves significantly before order execution could provide additional insights into system behavior.Include scenarios in testing where the market moves significantly before the execution of binary options limit orders to assess system behavior under such conditions.
- 1139-1188: The
test_msg_create_binary_options_market_orderfunction tests the creation of a binary options market order. It's crucial to verify that these orders are executed promptly and accurately, taking into account the unique payout structures of binary options. Testing against a range of market conditions would be beneficial.Expand testing of binary options market orders to include a wider range of market conditions, focusing on execution speed and accuracy.
- 1191-1230: In
test_msg_cancel_derivative_orderfor binary options, the cancellation logic is tested. Ensuring that binary options orders can be canceled efficiently and without unintended consequences is important for market integrity. Testing the cancellation process under high-frequency trading conditions could highlight potential areas for improvement.Test the cancellation process for binary options orders under high-frequency trading conditions to ensure efficiency and market integrity.
- 1232-1264: The
test_msg_subaccount_transfermethod tests the transfer of funds between subaccounts. This functionality is critical for managing funds within the platform. Ensuring that transfers are atomic and that the system correctly handles edge cases, such as insufficient funds, is essential.- 1266-1298: In
test_msg_external_transfer, the transfer of funds to an external subaccount is tested. Given the potential for funds to leave the platform, it's crucial to ensure that these transfers are secure and that all necessary validations are in place to prevent unauthorized or fraudulent transfers.- 1300-1331: The
test_msg_liquidate_positionfunction tests the liquidation of a position in a derivative market. This critical functionality must be thoroughly tested to ensure that liquidations are executed fairly and accurately, especially under extreme market conditions.Enhance testing of position liquidation to include scenarios of extreme market volatility and stress conditions to ensure fair and accurate execution.
- 1333-1352: In
test_msg_emergency_settle_market, the emergency settlement of a market is tested. This functionality is a critical safety mechanism and must be tested extensively to ensure that it can be executed reliably and without unintended consequences in real emergency situations.Conduct comprehensive testing of the emergency market settlement feature, including simulations of real emergency scenarios, to validate its reliability and effectiveness.
- 1355-1382: The
test_msg_external_transfermethod for increasing position margin in a derivative market is tested. Ensuring that margin increases are processed correctly and in a timely manner is crucial for maintaining the necessary collateral levels and preventing unintended liquidations.- 1385-1398: The
test_msg_rewards_opt_outfunction tests the opt-out functionality for rewards. This feature allows users to decline participation in reward programs, and it's important to ensure that the opt-out process is straightforward and irreversible, as desired by the user.- 1401-1431: In
test_msg_admin_update_binary_options_market, the administrative update of a binary options market is tested. Given the potential impact of administrative actions on market participants, it's crucial to ensure that these updates are authorized, logged, and transparent to all affected parties.tests/test_async_client_deprecation_warnings.py (1)
- 24-24: The correction in the import statement from
configurable_autz_query_servicertoconfigurable_authz_query_serviceris accurate and resolves a typo, ensuring the correct module is imported.pyinjective/composer.py (43)
- 140-143: The method
Coinis marked as deprecated with a warning to usecoininstead. This is a good practice for maintaining backward compatibility while guiding users towards the new method.- 164-167: The method
OrderDatais marked as deprecated with a warning to useorder_datainstead. Proper deprecation warnings are essential for a smooth transition to new methods.- 212-215: The method
SpotOrderis marked as deprecated with a warning to usespot_orderinstead. This consistent approach to deprecation across the file helps maintain code clarity and guides users effectively.- 304-307: The method
DerivativeOrderis marked as deprecated with a warning to usederivative_orderinstead. It's good to see a consistent pattern in handling deprecated methods across the file.- 489-493: The method
MsgDepositis marked as deprecated with a warning to usemsg_depositinstead. This deprecation notice is crucial for guiding users towards the updated method.- 511-515: The method
MsgWithdrawis marked as deprecated with a warning to usemsg_withdrawinstead. Consistent deprecation warnings across different methods help in maintaining backward compatibility while encouraging the use of updated methods.- 660-663: The method
MsgCreateSpotLimitOrderis marked as deprecated with a warning to usemsg_create_spot_limit_orderinstead. This approach ensures users are aware of the newer, preferred methods.- 717-721: The method
MsgBatchCreateSpotLimitOrdersis marked as deprecated with a warning to usemsg_batch_create_spot_limit_ordersinstead. This consistent approach to deprecation is beneficial for users transitioning to new methods.- 733-747: The method
MsgCreateSpotMarketOrderis marked as deprecated with a warning to usemsg_create_spot_market_orderinstead. Properly deprecating methods and guiding users to the new implementations is crucial for a smooth transition.- 792-803: The method
MsgCancelSpotOrderis marked as deprecated with a warning to usemsg_cancel_spot_orderinstead. This consistent deprecation strategy across the file helps users navigate the changes effectively.- 829-832: The method
MsgBatchCancelSpotOrdersis marked as deprecated with a warning to usemsg_batch_cancel_spot_ordersinstead. This approach ensures that users are informed about the newer, preferred methods.- 840-844: The method
MsgBatchUpdateOrdersis marked as deprecated with a warning to usemsg_batch_update_ordersinstead. Consistent deprecation warnings across different methods help in maintaining backward compatibility while encouraging the use of updated methods.- 887-893: The method
MsgPrivilegedExecuteContractis marked as deprecated with a warning to usemsg_privileged_execute_contractinstead. This deprecation notice is crucial for guiding users towards the updated method.- 929-932: The method
MsgCreateDerivativeLimitOrderis marked as deprecated with a warning to usemsg_create_derivative_limit_orderinstead. This approach ensures users are aware of the newer, preferred methods.- 1008-1013: The method
MsgBatchCreateDerivativeLimitOrdersis marked as deprecated with a warning to usemsg_batch_create_derivative_limit_ordersinstead. This consistent approach to deprecation is beneficial for users transitioning to new methods.- 1038-1041: The method
MsgCreateDerivativeMarketOrderis marked as deprecated with a warning to usemsg_create_derivative_market_orderinstead. Properly deprecating methods and guiding users to the new implementations is crucial for a smooth transition.- 1119-1129: The method
MsgCancelDerivativeOrderis marked as deprecated with a warning to usemsg_cancel_derivative_orderinstead. This consistent deprecation strategy across the file helps users navigate the changes effectively.- 1173-1177: The method
MsgBatchCancelDerivativeOrdersis marked as deprecated with a warning to usemsg_batch_cancel_derivative_ordersinstead. This approach ensures that users are informed about the newer, preferred methods.- 1207-1211: The method
MsgInstantBinaryOptionsMarketLaunchis marked as deprecated with a warning to usemsg_instant_binary_options_market_launchinstead. Consistent deprecation warnings across different methods help in maintaining backward compatibility while encouraging the use of updated methods.- 1299-1302: The method
MsgCreateBinaryOptionsLimitOrderis marked as deprecated with a warning to usemsg_create_binary_options_limit_orderinstead. This deprecation notice is crucial for guiding users towards the updated method.- 1393-1396: The method
MsgCreateBinaryOptionsMarketOrderis marked as deprecated with a warning to usemsg_create_binary_options_market_orderinstead. This approach ensures users are aware of the newer, preferred methods.- 1484-1487: The method
MsgCancelBinaryOptionsOrderis marked as deprecated with a warning to usemsg_cancel_binary_options_orderinstead. This consistent approach to deprecation is beneficial for users transitioning to new methods.- 1530-1533: The method
MsgSubaccountTransferis marked as deprecated with a warning to usemsg_subaccount_transferinstead. Properly deprecating methods and guiding users to the new implementations is crucial for a smooth transition.- 1572-1575: The method
MsgExternalTransferis marked as deprecated with a warning to usemsg_external_transferinstead. This consistent deprecation strategy across the file helps users navigate the changes effectively.- 1613-1616: The method
MsgLiquidatePositionis marked as deprecated with a warning to usemsg_liquidate_positioninstead. This approach ensures that users are informed about the newer, preferred methods.- 1654-1657: The method
MsgIncreasePositionMarginis marked as deprecated with a warning to usemsg_increase_position_margininstead. Consistent deprecation warnings across different methods help in maintaining backward compatibility while encouraging the use of updated methods.- 1692-1696: The method
MsgRewardsOptOutis marked as deprecated with a warning to usemsg_rewards_opt_outinstead. This deprecation notice is crucial for guiding users towards the updated method.- 1713-1716: The method
MsgAdminUpdateBinaryOptionsMarketis marked as deprecated with a warning to usemsg_admin_update_binary_options_marketinstead. This approach ensures users are aware of the newer, preferred methods.- 2107-2110: The method
MsgWithdrawDelegatorRewardis marked as deprecated with a warning to usemsg_withdraw_delegator_rewardinstead. This consistent approach to deprecation is beneficial for users transitioning to new methods.- 2121-2124: The method
MsgWithdrawValidatorCommissionis marked as deprecated with a warning to usemsg_withdraw_validator_commissioninstead. Properly deprecating methods and guiding users to the new implementations is crucial for a smooth transition.- 146-151: The new
coinmethod correctly creates an instance of theCoingRPC type, considering the amount is already expressed in chain format. This method simplifies the creation ofCoinobjects and is a good addition for better code readability and maintainability.- 153-159: The
create_coin_amountmethod is a valuable addition, allowing for the creation ofCoingRPC types with precise calculations using theDecimaltype. This method enhances the flexibility and accuracy of handling token amounts.- 182-192: The
order_datamethod introduces a more flexible way to createOrderDataobjects by allowing optional parameters for conditional, buy, and market order types. This method improves the modularity and usability of order creation within the SDK.- 249-281: The
spot_ordermethod is a significant improvement over its deprecated counterpart, offering more precise handling of quantities and prices using theDecimaltype and allowing for a clearer definition of order types. This method enhances the SDK's functionality for creating spot orders.- 362-393: The
derivative_ordermethod is a comprehensive addition that allows for the creation of derivative orders with detailed parameters, including margin and trigger price. This method significantly enhances the SDK's capabilities for handling derivative orders.- 395-427: The
binary_options_ordermethod is a new functionality that extends the SDK's capabilities to handle binary options orders. It introduces additional parameters likedenomfor special handling of quantities and prices, which is a valuable addition for users dealing with binary options.- 502-509: The
msg_depositmethod is a new addition that replaces the deprecatedMsgDepositmethod. It correctly uses theDecimaltype for the amount, enhancing the precision and flexibility of deposit operations within the SDK.- 524-531: The
msg_withdrawmethod is a new addition that replaces the deprecatedMsgWithdrawmethod. It correctly uses theDecimaltype for the amount, enhancing the precision and flexibility of withdrawal operations within the SDK.- 691-713: The
msg_create_spot_limit_ordermethod is a significant improvement over its deprecated counterpart, offering more precise handling of quantities and prices using theDecimaltype and allowing for a clearer definition of order types. This method enhances the SDK's functionality for creating spot limit orders.- 728-731: The
msg_batch_create_spot_limit_ordersmethod is a new addition that replaces the deprecatedMsgBatchCreateSpotLimitOrdersmethod. It correctly handles a list ofSpotOrderobjects, enhancing the SDK's batch processing capabilities for spot limit orders.- 766-790: The
msg_create_spot_market_ordermethod is a new addition that replaces the deprecatedMsgCreateSpotMarketOrdermethod. It introduces more precise handling of quantities and prices using theDecimaltype and allows for a clearer definition of order types, enhancing the SDK's functionality for creating spot market orders.- 812-826: The
msg_cancel_spot_ordermethod is a new addition that replaces the deprecatedMsgCancelSpotOrdermethod. It correctly handles optional parameters for conditional, buy, and market order types, enhancing the SDK's functionality for canceling spot orders.- 835-838: The
msg_batch_cancel_spot_ordersmethod is a new addition that replaces the deprecatedMsgBatchCancelSpotOrdersmethod. It correctly handles a list ofOrderDataobjects, enhancing the SDK's batch processing capabilities for canceling spot orders.pyinjective/async_client.py (5)
- 15-16: The addition of imports for
ChainGrpcDistributionApiandChainGrpcExchangeApiis aligned with the PR objectives to enhance theasync_client.pywith new functionalities for interacting with the Injective Protocol's distribution and exchange modules. This change is necessary for the subsequent use of these APIs within theAsyncClientclass.- 183-194: The initialization of
distribution_apiandchain_exchange_apiwithin theAsyncClientconstructor is correctly implemented. The use ofself.chain_channelas the channel and the lambda function formetadata_providerensures that these APIs can utilize the established gRPC channel and metadata for requests. This setup is essential for enabling the new functionalities related to the Injective Protocol's distribution and exchange modules as mentioned in the PR objectives.- 589-648: The methods added for fetching distribution information, such as
fetch_validator_distribution_info,fetch_validator_outstanding_rewards,fetch_validator_commission,fetch_validator_slashes,fetch_delegation_rewards,fetch_delegation_total_rewards,fetch_delegator_validators,fetch_delegator_withdraw_address, andfetch_community_pool, are correctly implemented. They utilize thedistribution_apito make the respective gRPC calls. This addition aligns with the PR objectives to enhance the client's capabilities in interacting with the distribution module of the Injective Protocol. It's important to ensure that these methods are accompanied by appropriate error handling and validation where necessary, although the specifics of such validations are not visible in the provided context.- 651-1037: The methods added for interacting with the Injective Protocol's exchange module, such as
fetch_subaccount_deposits,fetch_subaccount_deposit,fetch_exchange_balances,fetch_aggregate_volume,fetch_aggregate_volumes,fetch_aggregate_market_volume,fetch_aggregate_market_volumes,fetch_denom_decimal,fetch_denom_decimals,fetch_chain_spot_markets,fetch_chain_spot_market,fetch_chain_full_spot_markets,fetch_chain_full_spot_market,fetch_chain_spot_orderbook,fetch_chain_trader_spot_orders,fetch_chain_account_address_spot_orders,fetch_chain_spot_orders_by_hashes,fetch_chain_subaccount_orders,fetch_chain_trader_spot_transient_orders,fetch_spot_mid_price_and_tob,fetch_derivative_mid_price_and_tob,fetch_chain_derivative_orderbook,fetch_chain_trader_derivative_orders,fetch_chain_account_address_derivative_orders,fetch_chain_derivative_orders_by_hashes,fetch_chain_trader_derivative_transient_orders,fetch_chain_derivative_markets,fetch_chain_derivative_market,fetch_derivative_market_address,fetch_subaccount_trade_nonce,fetch_chain_positions,fetch_chain_subaccount_positions,fetch_chain_subaccount_position_in_market,fetch_chain_subaccount_effective_position_in_market,fetch_chain_perpetual_market_info,fetch_chain_expiry_futures_market_info,fetch_chain_perpetual_market_funding,fetch_subaccount_order_metadata,fetch_trade_reward_points,fetch_pending_trade_reward_points,fetch_trade_reward_campaign,fetch_fee_discount_account_info,fetch_fee_discount_schedule,fetch_balance_mismatches,fetch_balance_with_balance_holds,fetch_fee_discount_tier_statistics,fetch_mito_vault_infos,fetch_market_id_from_vault,fetch_historical_trade_records,fetch_is_opted_out_of_rewards,fetch_opted_out_of_rewards_accounts,fetch_market_volatility,fetch_chain_binary_options_markets,fetch_trader_derivative_conditional_orders, andfetch_market_atomic_execution_fee_multiplierare correctly implemented. These methods significantly expand the client's functionality, allowing for comprehensive interaction with various aspects of the exchange module. It's crucial that these methods are tested thoroughly to ensure they handle all possible edge cases and errors gracefully. Additionally, considering the extensive list of new functionalities, documentation should be updated accordingly to help users understand how to use these new methods effectively.- 3229-3236: The refactoring of the token representation logic within the
_token_representationmethod is a positive change that improves the maintainability and readability of the code. By extracting the logic for determining a unique symbol and creating aTokeninstance into a separate method, the code becomes more modular and easier to understand. This refactoring aligns with best practices for code organization and modularity. However, it's important to ensure that this method is called correctly throughout the class and that any changes to theTokenmodel or its usage are consistently applied.poetry.lock (16)
- 638-694: The update to "coverage" version "7.4.3" includes new wheel files for various Python versions and platforms, each with a corresponding SHA256 hash. Ensure that this version is compatible with the project's requirements and that the hashes match those from a trusted source, such as PyPI.
- 902-908: The update to "eth-abi" version "5.0.1" includes a wheel file and a source distribution, each with a SHA256 hash. Verify that this version is compatible with the project's requirements and confirm the hashes with a trusted source.
- 917-919: The extras for "eth-abi" have been updated to specify dependencies for development, documentation, testing, and tools. Review these extras to ensure they align with the project's development and deployment needs.
- 951-957: The update to "eth-hash" version "0.7.0" includes a wheel file and a source distribution, each with a SHA256 hash. Ensure this version is compatible with the project's requirements and verify the hashes with a trusted source.
- 972-978: The update to "eth-keyfile" version "0.8.0" includes a wheel file and a source distribution, each with a SHA256 hash. Verify that this version is compatible with the project's requirements and confirm the hashes with a trusted source.
- 1233-1361: The updates to "grpcio" and "grpcio-tools" version "1.62.0" include numerous wheel files for various Python versions and platforms, each with a SHA256 hash. Additionally, there's an update to the "grpcio-tools" package dependencies. Ensure these versions are compatible with the project's requirements, verify the hashes with a trusted source, and review the updated dependencies for "grpcio-tools".
- 1398-1404: The update to "identify" version "2.5.35" includes a wheel file and a source distribution, each with a SHA256 hash. Verify that this version is compatible with the project's requirements and confirm the hashes with a trusted source.
- 1788-1794: The update to "pre-commit" version "3.6.2" includes a wheel file and a source distribution, each with a SHA256 hash. Ensure this version is compatible with the project's requirements and verify the hashes with a trusted source.
- 1806-1821: The update to "protobuf" version "4.25.3" includes numerous wheel files for various Python versions and platforms, each with a SHA256 hash. Verify that this version is compatible with the project's requirements and confirm the hashes with a trusted source.
- 1915-1921: The update to "pytest" version "8.0.2" includes a wheel file and a source distribution, each with a SHA256 hash. Ensure this version is compatible with the project's requirements and verify the hashes with a trusted source.
- 1985-1998: The update to "python-dotenv" version "1.0.1" includes a wheel file and a source distribution, each with a SHA256 hash, and an update to the package extras specifying a dependency for the CLI. Verify that this version is compatible with the project's requirements, confirm the hashes with a trusted source, and review the updated extras for relevance.
- 2270-2373: The update to "rpds-py" version "0.18.0" includes numerous wheel files for various Python versions and platforms, each with a SHA256 hash. Ensure this version is compatible with the project's requirements and verify the hashes with a trusted source.
- 2388-2400: The update to "setuptools" version "69.1.1" includes a wheel file and a source distribution, each with a SHA256 hash, and an update to the package extras specifying dependencies for documentation and testing. Verify that this version is compatible with the project's requirements, confirm the hashes with a trusted source, and review the updated extras for relevance.
- 2448-2454: The update to "typing-extensions" version "4.10.0" includes a wheel file and a source distribution, each with a SHA256 hash. Ensure this version is compatible with the project's requirements and verify the hashes with a trusted source.
- 2475-2481: The update to "virtualenv" version "20.25.1" includes a wheel file and a source distribution, each with a SHA256 hash. Verify that this version is compatible with the project's requirements and confirm the hashes with a trusted source.
- 2715-2715: The metadata section has been updated with a new content-hash. This is a standard practice to ensure the integrity of the
poetry.lockfile after modifications.
Comment on lines
+9
to
+68
| class ConfigurableExchangeQueryServicer(exchange_query_grpc.QueryServicer): | ||
| def __init__(self): | ||
| super().__init__() | ||
| self.exchange_params = deque() | ||
| self.subaccount_deposits_responses = deque() | ||
| self.subaccount_deposit_responses = deque() | ||
| self.exchange_balances_responses = deque() | ||
| self.aggregate_volume_responses = deque() | ||
| self.aggregate_volumes_responses = deque() | ||
| self.aggregate_market_volume_responses = deque() | ||
| self.aggregate_market_volumes_responses = deque() | ||
| self.denom_decimal_responses = deque() | ||
| self.denom_decimals_responses = deque() | ||
| self.spot_markets_responses = deque() | ||
| self.spot_market_responses = deque() | ||
| self.full_spot_markets_responses = deque() | ||
| self.full_spot_market_responses = deque() | ||
| self.spot_orderbook_responses = deque() | ||
| self.trader_spot_orders_responses = deque() | ||
| self.account_address_spot_orders_responses = deque() | ||
| self.spot_orders_by_hashes_responses = deque() | ||
| self.subaccount_orders_responses = deque() | ||
| self.trader_spot_transient_orders_responses = deque() | ||
| self.spot_mid_price_and_tob_responses = deque() | ||
| self.derivative_mid_price_and_tob_responses = deque() | ||
| self.derivative_orderbook_responses = deque() | ||
| self.trader_derivative_orders_responses = deque() | ||
| self.account_address_derivative_orders_responses = deque() | ||
| self.derivative_orders_by_hashes_responses = deque() | ||
| self.trader_derivative_transient_orders_responses = deque() | ||
| self.derivative_markets_responses = deque() | ||
| self.derivative_market_responses = deque() | ||
| self.derivative_market_address_responses = deque() | ||
| self.subaccount_trade_nonce_responses = deque() | ||
| self.positions_responses = deque() | ||
| self.subaccount_positions_responses = deque() | ||
| self.subaccount_position_in_market_responses = deque() | ||
| self.subaccount_effective_position_in_market_responses = deque() | ||
| self.perpetual_market_info_responses = deque() | ||
| self.expiry_futures_market_info_responses = deque() | ||
| self.perpetual_market_funding_responses = deque() | ||
| self.subaccount_order_metadata_responses = deque() | ||
| self.trade_reward_points_responses = deque() | ||
| self.pending_trade_reward_points_responses = deque() | ||
| self.trade_reward_campaign_responses = deque() | ||
| self.fee_discount_account_info_responses = deque() | ||
| self.fee_discount_schedule_responses = deque() | ||
| self.balance_mismatches_responses = deque() | ||
| self.balance_with_balance_holds_responses = deque() | ||
| self.fee_discount_tier_statistics_responses = deque() | ||
| self.mito_vault_infos_responses = deque() | ||
| self.market_id_from_vault_responses = deque() | ||
| self.historical_trade_records_responses = deque() | ||
| self.is_opted_out_of_rewards_responses = deque() | ||
| self.opted_out_of_rewards_accounts_responses = deque() | ||
| self.market_volatility_responses = deque() | ||
| self.binary_options_markets_responses = deque() | ||
| self.trader_derivative_conditional_orders_responses = deque() | ||
| self.market_atomic_execution_fee_multiplier_responses = deque() | ||
|
|
Contributor
There was a problem hiding this comment.
The ConfigurableExchangeQueryServicer class is well-structured for mocking exchange query services. Using deque for mock responses is a good choice for FIFO behavior, which is typical in mock scenarios. However, ensure that there is a mechanism in place to handle cases where a pop() operation is called on an empty deque, as this will raise an IndexError. Consider adding checks or default responses to prevent potential runtime errors during testing.
Comment on lines
+69
to
+331
| async def QueryExchangeParams( | ||
| self, request: exchange_query_pb.QueryExchangeParamsRequest, context=None, metadata=None | ||
| ): | ||
| return self.exchange_params.pop() | ||
|
|
||
| async def SubaccountDeposits( | ||
| self, request: exchange_query_pb.QuerySubaccountDepositsRequest, context=None, metadata=None | ||
| ): | ||
| return self.subaccount_deposits_responses.pop() | ||
|
|
||
| async def SubaccountDeposit( | ||
| self, request: exchange_query_pb.QuerySubaccountDepositRequest, context=None, metadata=None | ||
| ): | ||
| return self.subaccount_deposit_responses.pop() | ||
|
|
||
| async def ExchangeBalances( | ||
| self, request: exchange_query_pb.QueryExchangeBalancesRequest, context=None, metadata=None | ||
| ): | ||
| return self.exchange_balances_responses.pop() | ||
|
|
||
| async def AggregateVolume( | ||
| self, request: exchange_query_pb.QueryAggregateVolumeRequest, context=None, metadata=None | ||
| ): | ||
| return self.aggregate_volume_responses.pop() | ||
|
|
||
| async def AggregateVolumes( | ||
| self, request: exchange_query_pb.QueryAggregateVolumesRequest, context=None, metadata=None | ||
| ): | ||
| return self.aggregate_volumes_responses.pop() | ||
|
|
||
| async def AggregateMarketVolume( | ||
| self, request: exchange_query_pb.QueryAggregateMarketVolumeRequest, context=None, metadata=None | ||
| ): | ||
| return self.aggregate_market_volume_responses.pop() | ||
|
|
||
| async def AggregateMarketVolumes( | ||
| self, request: exchange_query_pb.QueryAggregateMarketVolumesRequest, context=None, metadata=None | ||
| ): | ||
| return self.aggregate_market_volumes_responses.pop() | ||
|
|
||
| async def DenomDecimal(self, request: exchange_query_pb.QueryDenomDecimalRequest, context=None, metadata=None): | ||
| return self.denom_decimal_responses.pop() | ||
|
|
||
| async def DenomDecimals(self, request: exchange_query_pb.QueryDenomDecimalsRequest, context=None, metadata=None): | ||
| return self.denom_decimals_responses.pop() | ||
|
|
||
| async def SpotMarkets(self, request: exchange_query_pb.QuerySpotMarketsRequest, context=None, metadata=None): | ||
| return self.spot_markets_responses.pop() | ||
|
|
||
| async def SpotMarket(self, request: exchange_query_pb.QuerySpotMarketRequest, context=None, metadata=None): | ||
| return self.spot_market_responses.pop() | ||
|
|
||
| async def FullSpotMarkets( | ||
| self, request: exchange_query_pb.QueryFullSpotMarketsRequest, context=None, metadata=None | ||
| ): | ||
| return self.full_spot_markets_responses.pop() | ||
|
|
||
| async def FullSpotMarket(self, request: exchange_query_pb.QueryFullSpotMarketRequest, context=None, metadata=None): | ||
| return self.full_spot_market_responses.pop() | ||
|
|
||
| async def SpotOrderbook(self, request: exchange_query_pb.QuerySpotOrderbookRequest, context=None, metadata=None): | ||
| return self.spot_orderbook_responses.pop() | ||
|
|
||
| async def TraderSpotOrders( | ||
| self, request: exchange_query_pb.QueryTraderSpotOrdersRequest, context=None, metadata=None | ||
| ): | ||
| return self.trader_spot_orders_responses.pop() | ||
|
|
||
| async def AccountAddressSpotOrders( | ||
| self, request: exchange_query_pb.QueryAccountAddressSpotOrdersRequest, context=None, metadata=None | ||
| ): | ||
| return self.account_address_spot_orders_responses.pop() | ||
|
|
||
| async def SpotOrdersByHashes( | ||
| self, request: exchange_query_pb.QuerySpotOrdersByHashesRequest, context=None, metadata=None | ||
| ): | ||
| return self.spot_orders_by_hashes_responses.pop() | ||
|
|
||
| async def SubaccountOrders( | ||
| self, request: exchange_query_pb.QuerySubaccountOrdersRequest, context=None, metadata=None | ||
| ): | ||
| return self.subaccount_orders_responses.pop() | ||
|
|
||
| async def TraderSpotTransientOrders( | ||
| self, request: exchange_query_pb.QueryTraderSpotOrdersRequest, context=None, metadata=None | ||
| ): | ||
| return self.trader_spot_transient_orders_responses.pop() | ||
|
|
||
| async def SpotMidPriceAndTOB( | ||
| self, request: exchange_query_pb.QuerySpotMidPriceAndTOBRequest, context=None, metadata=None | ||
| ): | ||
| return self.spot_mid_price_and_tob_responses.pop() | ||
|
|
||
| async def DerivativeMidPriceAndTOB( | ||
| self, request: exchange_query_pb.QueryDerivativeMidPriceAndTOBRequest, context=None, metadata=None | ||
| ): | ||
| return self.derivative_mid_price_and_tob_responses.pop() | ||
|
|
||
| async def DerivativeOrderbook( | ||
| self, request: exchange_query_pb.QueryDerivativeOrderbookRequest, context=None, metadata=None | ||
| ): | ||
| return self.derivative_orderbook_responses.pop() | ||
|
|
||
| async def TraderDerivativeOrders( | ||
| self, request: exchange_query_pb.QueryTraderDerivativeOrdersRequest, context=None, metadata=None | ||
| ): | ||
| return self.trader_derivative_orders_responses.pop() | ||
|
|
||
| async def AccountAddressDerivativeOrders( | ||
| self, request: exchange_query_pb.QueryAccountAddressDerivativeOrdersRequest, context=None, metadata=None | ||
| ): | ||
| return self.account_address_derivative_orders_responses.pop() | ||
|
|
||
| async def DerivativeOrdersByHashes( | ||
| self, request: exchange_query_pb.QueryDerivativeOrdersByHashesRequest, context=None, metadata=None | ||
| ): | ||
| return self.derivative_orders_by_hashes_responses.pop() | ||
|
|
||
| async def TraderDerivativeTransientOrders( | ||
| self, request: exchange_query_pb.QueryTraderDerivativeOrdersRequest, context=None, metadata=None | ||
| ): | ||
| return self.trader_derivative_transient_orders_responses.pop() | ||
|
|
||
| async def DerivativeMarkets( | ||
| self, request: exchange_query_pb.QueryDerivativeMarketsRequest, context=None, metadata=None | ||
| ): | ||
| return self.derivative_markets_responses.pop() | ||
|
|
||
| async def DerivativeMarket( | ||
| self, request: exchange_query_pb.QueryDerivativeMarketRequest, context=None, metadata=None | ||
| ): | ||
| return self.derivative_market_responses.pop() | ||
|
|
||
| async def DerivativeMarketAddress( | ||
| self, request: exchange_query_pb.QueryDerivativeMarketAddressRequest, context=None, metadata=None | ||
| ): | ||
| return self.derivative_market_address_responses.pop() | ||
|
|
||
| async def SubaccountTradeNonce( | ||
| self, request: exchange_query_pb.QuerySubaccountTradeNonceRequest, context=None, metadata=None | ||
| ): | ||
| return self.subaccount_trade_nonce_responses.pop() | ||
|
|
||
| async def Positions(self, request: exchange_query_pb.QueryPositionsRequest, context=None, metadata=None): | ||
| return self.positions_responses.pop() | ||
|
|
||
| async def SubaccountPositions( | ||
| self, request: exchange_query_pb.QuerySubaccountPositionsRequest, context=None, metadata=None | ||
| ): | ||
| return self.subaccount_positions_responses.pop() | ||
|
|
||
| async def SubaccountPositionInMarket( | ||
| self, request: exchange_query_pb.QuerySubaccountPositionInMarketRequest, context=None, metadata=None | ||
| ): | ||
| return self.subaccount_position_in_market_responses.pop() | ||
|
|
||
| async def SubaccountEffectivePositionInMarket( | ||
| self, request: exchange_query_pb.QuerySubaccountEffectivePositionInMarketRequest, context=None, metadata=None | ||
| ): | ||
| return self.subaccount_effective_position_in_market_responses.pop() | ||
|
|
||
| async def PerpetualMarketInfo( | ||
| self, request: exchange_query_pb.QueryPerpetualMarketInfoRequest, context=None, metadata=None | ||
| ): | ||
| return self.perpetual_market_info_responses.pop() | ||
|
|
||
| async def ExpiryFuturesMarketInfo( | ||
| self, request: exchange_query_pb.QueryExpiryFuturesMarketInfoRequest, context=None, metadata=None | ||
| ): | ||
| return self.expiry_futures_market_info_responses.pop() | ||
|
|
||
| async def PerpetualMarketFunding( | ||
| self, request: exchange_query_pb.QueryPerpetualMarketFundingRequest, context=None, metadata=None | ||
| ): | ||
| return self.perpetual_market_funding_responses.pop() | ||
|
|
||
| async def SubaccountOrderMetadata( | ||
| self, request: exchange_query_pb.QuerySubaccountOrderMetadataRequest, context=None, metadata=None | ||
| ): | ||
| return self.subaccount_order_metadata_responses.pop() | ||
|
|
||
| async def TradeRewardPoints( | ||
| self, request: exchange_query_pb.QueryTradeRewardPointsRequest, context=None, metadata=None | ||
| ): | ||
| return self.trade_reward_points_responses.pop() | ||
|
|
||
| async def PendingTradeRewardPoints( | ||
| self, request: exchange_query_pb.QueryTradeRewardPointsRequest, context=None, metadata=None | ||
| ): | ||
| return self.pending_trade_reward_points_responses.pop() | ||
|
|
||
| async def TradeRewardCampaign( | ||
| self, request: exchange_query_pb.QueryTradeRewardCampaignRequest, context=None, metadata=None | ||
| ): | ||
| return self.trade_reward_campaign_responses.pop() | ||
|
|
||
| async def FeeDiscountAccountInfo( | ||
| self, request: exchange_query_pb.QueryFeeDiscountAccountInfoRequest, context=None, metadata=None | ||
| ): | ||
| return self.fee_discount_account_info_responses.pop() | ||
|
|
||
| async def FeeDiscountSchedule( | ||
| self, request: exchange_query_pb.QueryFeeDiscountScheduleRequest, context=None, metadata=None | ||
| ): | ||
| return self.fee_discount_schedule_responses.pop() | ||
|
|
||
| async def BalanceMismatches( | ||
| self, request: exchange_query_pb.QueryBalanceMismatchesRequest, context=None, metadata=None | ||
| ): | ||
| return self.balance_mismatches_responses.pop() | ||
|
|
||
| async def BalanceWithBalanceHolds( | ||
| self, request: exchange_query_pb.QueryBalanceWithBalanceHoldsRequest, context=None, metadata=None | ||
| ): | ||
| return self.balance_with_balance_holds_responses.pop() | ||
|
|
||
| async def FeeDiscountTierStatistics( | ||
| self, request: exchange_query_pb.QueryFeeDiscountTierStatisticsRequest, context=None, metadata=None | ||
| ): | ||
| return self.fee_discount_tier_statistics_responses.pop() | ||
|
|
||
| async def MitoVaultInfos(self, request: exchange_query_pb.MitoVaultInfosRequest, context=None, metadata=None): | ||
| return self.mito_vault_infos_responses.pop() | ||
|
|
||
| async def QueryMarketIDFromVault( | ||
| self, request: exchange_query_pb.QueryMarketIDFromVaultRequest, context=None, metadata=None | ||
| ): | ||
| return self.market_id_from_vault_responses.pop() | ||
|
|
||
| async def HistoricalTradeRecords( | ||
| self, request: exchange_query_pb.QueryHistoricalTradeRecordsRequest, context=None, metadata=None | ||
| ): | ||
| return self.historical_trade_records_responses.pop() | ||
|
|
||
| async def IsOptedOutOfRewards( | ||
| self, request: exchange_query_pb.QueryIsOptedOutOfRewardsRequest, context=None, metadata=None | ||
| ): | ||
| return self.is_opted_out_of_rewards_responses.pop() | ||
|
|
||
| async def OptedOutOfRewardsAccounts( | ||
| self, request: exchange_query_pb.QueryOptedOutOfRewardsAccountsRequest, context=None, metadata=None | ||
| ): | ||
| return self.opted_out_of_rewards_accounts_responses.pop() | ||
|
|
||
| async def MarketVolatility( | ||
| self, request: exchange_query_pb.QueryMarketVolatilityRequest, context=None, metadata=None | ||
| ): | ||
| return self.market_volatility_responses.pop() | ||
|
|
||
| async def BinaryOptionsMarkets( | ||
| self, request: exchange_query_pb.QueryBinaryMarketsRequest, context=None, metadata=None | ||
| ): | ||
| return self.binary_options_markets_responses.pop() | ||
|
|
||
| async def TraderDerivativeConditionalOrders( | ||
| self, request: exchange_query_pb.QueryTraderDerivativeConditionalOrdersRequest, context=None, metadata=None | ||
| ): | ||
| return self.trader_derivative_conditional_orders_responses.pop() | ||
|
|
||
| async def MarketAtomicExecutionFeeMultiplier( | ||
| self, request: exchange_query_pb.QueryMarketAtomicExecutionFeeMultiplierRequest, context=None, metadata=None | ||
| ): | ||
| return self.market_atomic_execution_fee_multiplier_responses.pop() |
Contributor
There was a problem hiding this comment.
Each async method in ConfigurableExchangeQueryServicer correctly pops a response from its respective deque. This setup is crucial for testing different scenarios by preloading the deque with expected responses. However, it's important to ensure that all methods have corresponding test cases that cover various scenarios, including empty responses and error cases. This will help in validating the robustness of the application's error handling and response parsing logic.
Would you like me to help generate some test cases covering various scenarios for these methods?
| assert len(deprecation_warnings) == 1 | ||
| assert str(deprecation_warnings[0].message) == "This method is deprecated. Use msg_withdraw instead" | ||
|
|
||
| def teste_order_data_deprecation_warning(self): |
Contributor
There was a problem hiding this comment.
There's a typo in the method name teste_order_data_deprecation_warning. It should be test_order_data_deprecation_warning.
- def teste_order_data_deprecation_warning(self):
+ def test_order_data_deprecation_warning(self):Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
Suggested change
| def teste_order_data_deprecation_warning(self): | |
| def test_order_data_deprecation_warning(self): |
Comment on lines
+13
to
+578
| class ChainGrpcExchangeApi: | ||
| def __init__(self, channel: Channel, metadata_provider: Callable): | ||
| self._stub = exchange_query_grpc.QueryStub(channel) | ||
| self._assistant = GrpcApiRequestAssistant(metadata_provider=metadata_provider) | ||
|
|
||
| async def fetch_exchange_params(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryExchangeParamsRequest() | ||
| response = await self._execute_call(call=self._stub.QueryExchangeParams, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_subaccount_deposits( | ||
| self, | ||
| subaccount_id: Optional[str] = None, | ||
| subaccount_trader: Optional[str] = None, | ||
| subaccount_nonce: Optional[int] = None, | ||
| ) -> Dict[str, Any]: | ||
| subaccount = None | ||
| if subaccount_trader is not None or subaccount_nonce is not None: | ||
| subaccount = exchange_query_pb.Subaccount( | ||
| trader=subaccount_trader, | ||
| subaccount_nonce=subaccount_nonce, | ||
| ) | ||
|
|
||
| request = exchange_query_pb.QuerySubaccountDepositsRequest(subaccount_id=subaccount_id, subaccount=subaccount) | ||
| response = await self._execute_call(call=self._stub.SubaccountDeposits, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_subaccount_deposit( | ||
| self, | ||
| subaccount_id: str, | ||
| denom: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySubaccountDepositRequest( | ||
| subaccount_id=subaccount_id, | ||
| denom=denom, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.SubaccountDeposit, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_exchange_balances(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryExchangeBalancesRequest() | ||
| response = await self._execute_call(call=self._stub.ExchangeBalances, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_aggregate_volume(self, account: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryAggregateVolumeRequest(account=account) | ||
| response = await self._execute_call(call=self._stub.AggregateVolume, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_aggregate_volumes( | ||
| self, | ||
| accounts: Optional[List[str]] = None, | ||
| market_ids: Optional[List[str]] = None, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryAggregateVolumesRequest(accounts=accounts, market_ids=market_ids) | ||
| response = await self._execute_call(call=self._stub.AggregateVolumes, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_aggregate_market_volume(self, market_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryAggregateMarketVolumeRequest(market_id=market_id) | ||
| response = await self._execute_call(call=self._stub.AggregateMarketVolume, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_aggregate_market_volumes(self, market_ids: Optional[List[str]] = None) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryAggregateMarketVolumesRequest(market_ids=market_ids) | ||
| response = await self._execute_call(call=self._stub.AggregateMarketVolumes, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_denom_decimal(self, denom: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryDenomDecimalRequest(denom=denom) | ||
| response = await self._execute_call(call=self._stub.DenomDecimal, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_denom_decimals(self, denoms: Optional[List[str]] = None) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryDenomDecimalsRequest(denoms=denoms) | ||
| response = await self._execute_call(call=self._stub.DenomDecimals, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_spot_markets( | ||
| self, | ||
| status: Optional[str] = None, | ||
| market_ids: Optional[List[str]] = None, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySpotMarketsRequest( | ||
| status=status, | ||
| market_ids=market_ids, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.SpotMarkets, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_spot_market(self, market_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySpotMarketRequest(market_id=market_id) | ||
| response = await self._execute_call(call=self._stub.SpotMarket, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_full_spot_markets( | ||
| self, | ||
| status: Optional[str] = None, | ||
| market_ids: Optional[List[str]] = None, | ||
| with_mid_price_and_tob: Optional[bool] = None, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryFullSpotMarketsRequest( | ||
| status=status, | ||
| market_ids=market_ids, | ||
| with_mid_price_and_tob=with_mid_price_and_tob, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.FullSpotMarkets, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_full_spot_market( | ||
| self, | ||
| market_id: str, | ||
| with_mid_price_and_tob: Optional[bool] = None, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryFullSpotMarketRequest( | ||
| market_id=market_id, | ||
| with_mid_price_and_tob=with_mid_price_and_tob, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.FullSpotMarket, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_spot_orderbook( | ||
| self, | ||
| market_id: str, | ||
| order_side: Optional[str] = None, | ||
| limit_cumulative_notional: Optional[str] = None, | ||
| limit_cumulative_quantity: Optional[str] = None, | ||
| pagination: Optional[PaginationOption] = None, | ||
| ) -> Dict[str, Any]: | ||
| limit = None | ||
| if pagination is not None: | ||
| limit = pagination.limit | ||
| request = exchange_query_pb.QuerySpotOrderbookRequest( | ||
| market_id=market_id, | ||
| order_side=order_side, | ||
| limit=limit, | ||
| limit_cumulative_notional=limit_cumulative_notional, | ||
| limit_cumulative_quantity=limit_cumulative_quantity, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.SpotOrderbook, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_trader_spot_orders( | ||
| self, | ||
| market_id: str, | ||
| subaccount_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryTraderSpotOrdersRequest( | ||
| market_id=market_id, | ||
| subaccount_id=subaccount_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.TraderSpotOrders, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_account_address_spot_orders( | ||
| self, | ||
| market_id: str, | ||
| account_address: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryAccountAddressSpotOrdersRequest( | ||
| market_id=market_id, | ||
| account_address=account_address, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.AccountAddressSpotOrders, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_spot_orders_by_hashes( | ||
| self, | ||
| market_id: str, | ||
| subaccount_id: str, | ||
| order_hashes: List[str], | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySpotOrdersByHashesRequest( | ||
| market_id=market_id, | ||
| subaccount_id=subaccount_id, | ||
| order_hashes=order_hashes, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.SpotOrdersByHashes, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_subaccount_orders( | ||
| self, | ||
| subaccount_id: str, | ||
| market_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySubaccountOrdersRequest( | ||
| subaccount_id=subaccount_id, | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.SubaccountOrders, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_trader_spot_transient_orders( | ||
| self, | ||
| market_id: str, | ||
| subaccount_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryTraderSpotOrdersRequest( | ||
| market_id=market_id, | ||
| subaccount_id=subaccount_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.TraderSpotTransientOrders, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_spot_mid_price_and_tob( | ||
| self, | ||
| market_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySpotMidPriceAndTOBRequest( | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.SpotMidPriceAndTOB, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_derivative_mid_price_and_tob( | ||
| self, | ||
| market_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryDerivativeMidPriceAndTOBRequest( | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.DerivativeMidPriceAndTOB, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_derivative_orderbook( | ||
| self, | ||
| market_id: str, | ||
| limit_cumulative_notional: Optional[str] = None, | ||
| pagination: Optional[PaginationOption] = None, | ||
| ) -> Dict[str, Any]: | ||
| limit = None | ||
| if pagination is not None: | ||
| limit = pagination.limit | ||
| request = exchange_query_pb.QueryDerivativeOrderbookRequest( | ||
| market_id=market_id, | ||
| limit=limit, | ||
| limit_cumulative_notional=limit_cumulative_notional, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.DerivativeOrderbook, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_trader_derivative_orders( | ||
| self, | ||
| market_id: str, | ||
| subaccount_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryTraderDerivativeOrdersRequest( | ||
| market_id=market_id, | ||
| subaccount_id=subaccount_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.TraderDerivativeOrders, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_account_address_derivative_orders( | ||
| self, | ||
| market_id: str, | ||
| account_address: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryAccountAddressDerivativeOrdersRequest( | ||
| market_id=market_id, | ||
| account_address=account_address, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.AccountAddressDerivativeOrders, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_derivative_orders_by_hashes( | ||
| self, | ||
| market_id: str, | ||
| subaccount_id: str, | ||
| order_hashes: List[str], | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryDerivativeOrdersByHashesRequest( | ||
| market_id=market_id, | ||
| subaccount_id=subaccount_id, | ||
| order_hashes=order_hashes, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.DerivativeOrdersByHashes, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_trader_derivative_transient_orders( | ||
| self, | ||
| market_id: str, | ||
| subaccount_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryTraderDerivativeOrdersRequest( | ||
| market_id=market_id, | ||
| subaccount_id=subaccount_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.TraderDerivativeTransientOrders, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_derivative_markets( | ||
| self, | ||
| status: Optional[str] = None, | ||
| market_ids: Optional[List[str]] = None, | ||
| with_mid_price_and_tob: Optional[bool] = None, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryDerivativeMarketsRequest( | ||
| status=status, | ||
| market_ids=market_ids, | ||
| with_mid_price_and_tob=with_mid_price_and_tob, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.DerivativeMarkets, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_derivative_market( | ||
| self, | ||
| market_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryDerivativeMarketRequest( | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.DerivativeMarket, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_derivative_market_address( | ||
| self, | ||
| market_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryDerivativeMarketAddressRequest( | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.DerivativeMarketAddress, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_subaccount_trade_nonce(self, subaccount_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySubaccountTradeNonceRequest(subaccount_id=subaccount_id) | ||
| response = await self._execute_call(call=self._stub.SubaccountTradeNonce, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_positions(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryPositionsRequest() | ||
| response = await self._execute_call(call=self._stub.Positions, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_subaccount_positions(self, subaccount_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySubaccountPositionsRequest(subaccount_id=subaccount_id) | ||
| response = await self._execute_call(call=self._stub.SubaccountPositions, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_subaccount_position_in_market(self, subaccount_id: str, market_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySubaccountPositionInMarketRequest( | ||
| subaccount_id=subaccount_id, | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.SubaccountPositionInMarket, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_subaccount_effective_position_in_market(self, subaccount_id: str, market_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySubaccountEffectivePositionInMarketRequest( | ||
| subaccount_id=subaccount_id, | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.SubaccountEffectivePositionInMarket, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_perpetual_market_info(self, market_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryPerpetualMarketInfoRequest(market_id=market_id) | ||
| response = await self._execute_call(call=self._stub.PerpetualMarketInfo, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_expiry_futures_market_info(self, market_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryExpiryFuturesMarketInfoRequest(market_id=market_id) | ||
| response = await self._execute_call(call=self._stub.ExpiryFuturesMarketInfo, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_perpetual_market_funding(self, market_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryPerpetualMarketFundingRequest(market_id=market_id) | ||
| response = await self._execute_call(call=self._stub.PerpetualMarketFunding, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_subaccount_order_metadata(self, subaccount_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QuerySubaccountOrderMetadataRequest(subaccount_id=subaccount_id) | ||
| response = await self._execute_call(call=self._stub.SubaccountOrderMetadata, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_trade_reward_points( | ||
| self, | ||
| accounts: Optional[List[str]] = None, | ||
| pending_pool_timestamp: Optional[int] = None, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryTradeRewardPointsRequest( | ||
| accounts=accounts, | ||
| pending_pool_timestamp=pending_pool_timestamp, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.TradeRewardPoints, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_pending_trade_reward_points( | ||
| self, | ||
| accounts: Optional[List[str]] = None, | ||
| pending_pool_timestamp: Optional[int] = None, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryTradeRewardPointsRequest( | ||
| accounts=accounts, | ||
| pending_pool_timestamp=pending_pool_timestamp, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.PendingTradeRewardPoints, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_trade_reward_campaign(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryTradeRewardCampaignRequest() | ||
| response = await self._execute_call(call=self._stub.TradeRewardCampaign, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_fee_discount_account_info( | ||
| self, | ||
| account: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryFeeDiscountAccountInfoRequest(account=account) | ||
| response = await self._execute_call(call=self._stub.FeeDiscountAccountInfo, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_fee_discount_schedule(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryFeeDiscountScheduleRequest() | ||
| response = await self._execute_call(call=self._stub.FeeDiscountSchedule, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_balance_mismatches(self, dust_factor: int) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryBalanceMismatchesRequest(dust_factor=dust_factor) | ||
| response = await self._execute_call(call=self._stub.BalanceMismatches, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_balance_with_balance_holds(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryBalanceWithBalanceHoldsRequest() | ||
| response = await self._execute_call(call=self._stub.BalanceWithBalanceHolds, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_fee_discount_tier_statistics(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryFeeDiscountTierStatisticsRequest() | ||
| response = await self._execute_call(call=self._stub.FeeDiscountTierStatistics, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_mito_vault_infos(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.MitoVaultInfosRequest() | ||
| response = await self._execute_call(call=self._stub.MitoVaultInfos, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_market_id_from_vault(self, vault_address: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryMarketIDFromVaultRequest(vault_address=vault_address) | ||
| response = await self._execute_call(call=self._stub.QueryMarketIDFromVault, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_historical_trade_records(self, market_id: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryHistoricalTradeRecordsRequest(market_id=market_id) | ||
| response = await self._execute_call(call=self._stub.HistoricalTradeRecords, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_is_opted_out_of_rewards(self, account: str) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryIsOptedOutOfRewardsRequest(account=account) | ||
| response = await self._execute_call(call=self._stub.IsOptedOutOfRewards, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_opted_out_of_rewards_accounts(self) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryOptedOutOfRewardsAccountsRequest() | ||
| response = await self._execute_call(call=self._stub.OptedOutOfRewardsAccounts, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_market_volatility( | ||
| self, | ||
| market_id: str, | ||
| trade_grouping_sec: Optional[int] = None, | ||
| max_age: Optional[int] = None, | ||
| include_raw_history: Optional[bool] = None, | ||
| include_metadata: Optional[bool] = None, | ||
| ) -> Dict[str, Any]: | ||
| trade_history_options = exchange_query_pb.TradeHistoryOptions() | ||
| if trade_grouping_sec is not None: | ||
| trade_history_options.trade_grouping_sec = trade_grouping_sec | ||
| if max_age is not None: | ||
| trade_history_options.max_age = max_age | ||
| if include_raw_history is not None: | ||
| trade_history_options.include_raw_history = include_raw_history | ||
| if include_metadata is not None: | ||
| trade_history_options.include_metadata = include_metadata | ||
| request = exchange_query_pb.QueryMarketVolatilityRequest( | ||
| market_id=market_id, trade_history_options=trade_history_options | ||
| ) | ||
| response = await self._execute_call(call=self._stub.MarketVolatility, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_binary_options_markets(self, status: Optional[str] = None) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryBinaryMarketsRequest(status=status) | ||
| response = await self._execute_call(call=self._stub.BinaryOptionsMarkets, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_trader_derivative_conditional_orders( | ||
| self, | ||
| subaccount_id: Optional[str] = None, | ||
| market_id: Optional[str] = None, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryTraderDerivativeConditionalOrdersRequest( | ||
| subaccount_id=subaccount_id, | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.TraderDerivativeConditionalOrders, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def fetch_market_atomic_execution_fee_multiplier( | ||
| self, | ||
| market_id: str, | ||
| ) -> Dict[str, Any]: | ||
| request = exchange_query_pb.QueryMarketAtomicExecutionFeeMultiplierRequest( | ||
| market_id=market_id, | ||
| ) | ||
| response = await self._execute_call(call=self._stub.MarketAtomicExecutionFeeMultiplier, request=request) | ||
|
|
||
| return response | ||
|
|
||
| async def _execute_call(self, call: Callable, request) -> Dict[str, Any]: | ||
| return await self._assistant.execute_call(call=call, request=request) |
Contributor
There was a problem hiding this comment.
Ensure comprehensive test coverage for all methods in the ChainGrpcExchangeApi class. Given the complexity of interacting with a blockchain protocol, it's crucial to validate the correctness and resilience of these methods under various conditions.
Would you like assistance in generating tests or enhancing existing ones to cover these functionalities?
| import asyncio | ||
| import os | ||
|
|
||
| import dotenv |
Contributor
There was a problem hiding this comment.
The import statement for dotenv is correct, but it's more conventional to use from dotenv import load_dotenv and then simply call load_dotenv() without the module prefix.
- import dotenv
+ from dotenv import load_dotenvCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
Suggested change
| import dotenv | |
| from dotenv import load_dotenv |
Comment on lines
+36
to
+51
| message = composer.msg_instant_binary_options_market_launch( | ||
| sender=address.to_acc_bech32(), | ||
| ticker="UFC-KHABIB-TKO-05/30/2023", | ||
| oracle_symbol="UFC-KHABIB-TKO-05/30/2023", | ||
| oracle_provider="UFC", | ||
| oracle_type="Provider", | ||
| oracle_scale_factor=6, | ||
| maker_fee_rate=0.0005, # 0.05% | ||
| taker_fee_rate=0.0010, # 0.10% | ||
| expiration_timestamp=1680730982, | ||
| settlement_timestamp=1690730982, | ||
| admin=address.to_acc_bech32(), | ||
| quote_denom="peggy0xdAC17F958D2ee523a2206206994597C13D831ec7", | ||
| min_price_tick_size=0.01, | ||
| min_quantity_tick_size=0.01, | ||
| ) |
Contributor
There was a problem hiding this comment.
The parameters for launching the binary options market, such as ticker, oracle_symbol, oracle_provider, oracle_type, maker_fee_rate, taker_fee_rate, expiration_timestamp, settlement_timestamp, quote_denom, min_price_tick_size, and min_quantity_tick_size are hardcoded. While this might be suitable for example purposes, consider fetching these values from an environment variable or a configuration file to enhance flexibility and usability in real-world scenarios.
Comment on lines
+37
to
+38
| if __name__ == "__main__": | ||
| asyncio.get_event_loop().run_until_complete(main()) |
Contributor
There was a problem hiding this comment.
Recommend updating the method for running the async main function to asyncio.run(main()) for Python 3.7 and newer, which simplifies the entry point and ensures proper event loop management.
- asyncio.get_event_loop().run_until_complete(main())
+ asyncio.run(main())Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
Suggested change
| if __name__ == "__main__": | |
| asyncio.get_event_loop().run_until_complete(main()) | |
| if __name__ == "__main__": | |
| asyncio.run(main()) |
Comment on lines
+12
to
+13
| dotenv.load_dotenv() | ||
| configured_private_key = os.getenv("INJECTIVE_PRIVATE_KEY") |
Contributor
There was a problem hiding this comment.
Include error handling for the scenario where the INJECTIVE_PRIVATE_KEY environment variable is not set, to prevent runtime errors and improve the script's robustness, as done in previous files.
- configured_private_key = os.getenv("INJECTIVE_PRIVATE_KEY")
+ configured_private_key = os.getenv("INJECTIVE_PRIVATE_KEY", "")
+ if not configured_private_key:
+ raise ValueError("INJECTIVE_PRIVATE_KEY environment variable is not set.")Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
Suggested change
| dotenv.load_dotenv() | |
| configured_private_key = os.getenv("INJECTIVE_PRIVATE_KEY") | |
| dotenv.load_dotenv() | |
| configured_private_key = os.getenv("INJECTIVE_PRIVATE_KEY", "") | |
| if not configured_private_key: | |
| raise ValueError("INJECTIVE_PRIVATE_KEY environment variable is not set.") |
Comment on lines
+37
to
+38
| if __name__ == "__main__": | ||
| asyncio.get_event_loop().run_until_complete(main()) |
Contributor
There was a problem hiding this comment.
Recommend updating the method for running the async main function to asyncio.run(main()) for Python 3.7 and newer, which simplifies the entry point and ensures proper event loop management.
- asyncio.get_event_loop().run_until_complete(main())
+ asyncio.run(main())Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
Suggested change
| if __name__ == "__main__": | |
| asyncio.get_event_loop().run_until_complete(main()) | |
| if __name__ == "__main__": | |
| asyncio.run(main()) |
Comment on lines
+13
to
+14
| dotenv.load_dotenv() | ||
| private_key_in_hexa = os.getenv("INJECTIVE_PRIVATE_KEY") |
Contributor
There was a problem hiding this comment.
Ensure that there's error handling for the case where the INJECTIVE_PRIVATE_KEY environment variable might not be set. This is crucial for avoiding runtime errors and improving the script's robustness.
- private_key_in_hexa = os.getenv("INJECTIVE_PRIVATE_KEY")
+ private_key_in_hexa = os.getenv("INJECTIVE_PRIVATE_KEY", "")
+ if not private_key_in_hexa:
+ raise ValueError("INJECTIVE_PRIVATE_KEY environment variable is not set.")Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
Suggested change
| dotenv.load_dotenv() | |
| private_key_in_hexa = os.getenv("INJECTIVE_PRIVATE_KEY") | |
| dotenv.load_dotenv() | |
| private_key_in_hexa = os.getenv("INJECTIVE_PRIVATE_KEY", "") | |
| if not private_key_in_hexa: | |
| raise ValueError("INJECTIVE_PRIVATE_KEY environment variable is not set.") |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
devbranch (v1.4.0) tomasterSummary by CodeRabbit
.coderabbit.yamlconfiguration.dotenvin example scripts.ChainGrpcDistributionApiandChainGrpcExchangeApifor distribution and exchange operations.python-dotenvdependency for environment variable management.