Added limit as a configurable variable to DeployablePredictionAgent #532
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughThe changes in this pull request modify the Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
prediction_market_agent_tooling/deploy/agent.py (1)
374-374: LGTM! Consider relocating the comment.The changes to
get_marketsimprove flexibility by allowing runtime override of the fetch limit while maintaining good defaults. However, the comment "Fetch the soonest closing markets to choose from" would be more appropriate above theavailable_marketsassignment since it describes the sorting behavior.cls = market_type.market_class - # Fetch the soonest closing markets to choose from limit = limit if limit else self.n_markets_to_fetch + # Fetch the soonest closing markets to choose from available_markets = cls.get_binary_markets( limit=limit, sort_by=sort_by, filter_by=filter_by )Also applies to: 380-380
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
poetry.lockis excluded by!**/*.lock,!**/*.lockpyproject.tomlis excluded by!**/*.toml
📒 Files selected for processing (1)
- prediction_market_agent_tooling/deploy/agent.py (2 hunks)
🔇 Additional comments (1)
prediction_market_agent_tooling/deploy/agent.py (1)
282-282: LGTM! Well-placed configuration variable.The addition of
n_markets_to_fetchas a class variable improves configurability while maintaining backward compatibility with the default value ofMAX_AVAILABLE_MARKETS.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
tests_integration_with_local_chain/safe/conftest.py (1)
Safe import inconsistency found across the codebase
The codebase currently has mixed imports for the Safe class:
- Most files use
from gnosis.safe import Safe- One file uses
from gnosis.safe.safe import Safe- One file uses
from safe_eth.safe import SafeFiles to update for consistency:
prediction_market_agent_tooling/tools/safe.py(usingsafe_eth.safe)prediction_market_agent_tooling/tools/web3_utils.py(usinggnosis.safe.safe)- All other files use
gnosis.safe🔗 Analysis chain
Line range hint
3-4: Verify Safe import source consistency.The AI summary indicates that Safe imports were changed from 'gnosis.safe.safe' to 'safe_eth.safe' across the codebase, but this file still imports from 'gnosis.safe'. This inconsistency might lead to type checking issues.
Let's verify the Safe import usage across the codebase:
Also applies to: 35-35
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check Safe import patterns across the codebase # Expected: Consistent use of either 'gnosis.safe' or 'safe_eth.safe' echo "Checking Safe imports..." rg -l "from .*safe import Safe" echo -e "\nChecking Safe usage patterns..." ast-grep --pattern 'from $_ import Safe'Length of output: 1046
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- prediction_market_agent_tooling/config.py (1 hunks)
- prediction_market_agent_tooling/tools/safe.py (4 hunks)
- prediction_market_agent_tooling/tools/web3_utils.py (1 hunks)
- tests_integration_with_local_chain/safe/conftest.py (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- prediction_market_agent_tooling/tools/web3_utils.py
🔇 Additional comments (5)
tests_integration_with_local_chain/safe/conftest.py (1)
35-35: LGTM: Type ignore removal.The removal of the type ignore comment suggests that the underlying type issue has been resolved, which improves code quality.
prediction_market_agent_tooling/tools/safe.py (3)
91-91: Clean type handling improvement.Good improvement removing the type ignore comment. The code is now properly typed with the new
safe_ethlibrary.
116-118: Good addition of explicit type safety.The explicit
ChecksumAddresstype annotation improves code safety and clarity.
131-135: Verify impact of return type change.The new return statement is more robust by ensuring checksum address format and explicit None handling. However, this change might affect existing callers.
✅ Verification successful
Return type change is safe to proceed
The return type change is safe because:
- All callers already handle the None case correctly (e.g.,
create_safe_for_agent.pychecksif not safe_address)- The address is consistently converted to checksum format in all places where it's used (e.g., in
bet_omen.py,sell_all_omen.py, etc.)- The test in
conftest.pyexplicitly asserts for non-None value before usage🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check usage of create_safe function to verify compatibility with new return type # Find direct usage of create_safe function echo "Checking direct create_safe usage..." ast-grep --pattern 'create_safe($$$)' # Check for potential address comparisons that might be affected by checksum conversion echo "Checking address comparisons..." rg -A 2 "create_safe\(.*\)"Length of output: 1335
Script:
#!/bin/bash # Let's check how the return value of create_safe is used in the calling code # Check the usage context in test files echo "Checking usage in tests..." rg -B 2 -A 4 "safe_address = create_safe" tests_integration_with_local_chain/ # Check the usage in scripts echo "Checking usage in scripts..." rg -B 2 -A 4 "safe_address = create_safe" scripts/ # Check if there are any address comparisons or validations done on the safe_address echo "Checking address handling..." rg -A 2 "safe_address" tests_integration_with_local_chain/ scripts/Length of output: 7016
prediction_market_agent_tooling/config.py (1)
203-203: LGTM! Type safety improvements.The changes improve type safety by:
- Removing the type ignore comment, indicating better type compatibility
- Adding explicit boolean conversion to ensure a strict boolean return type
Let's verify the type compatibility of the Safe instantiation:
Also applies to: 205-205
✅ Verification successful
Type safety improvements verified successfully
The verification confirms:
- No remaining type-ignore comments related to Safe instantiation
- Consistent Safe imports across the codebase (
from gnosis.safe import Safe)- The import pattern is used correctly in both production code (
prediction_market_agent_tooling/config.py) and test files🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining type ignore comments related to Safe instantiation # and verify the import changes across the codebase # Test 1: Check for any remaining type ignore comments related to Safe rg -i "# type.*ignore.*safe" # Test 2: Verify Safe import consistency rg "from gnosis.safe import Safe"Length of output: 403
Co-authored-by: Evan Griffiths <[email protected]>
Co-authored-by: Evan Griffiths <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
tests_integration_with_local_chain/safe/conftest.py (1)
Line range hint 17-35: Consider documenting Safe version selection
The fixture is using a specific Safe contract version (V141) but lacks documentation explaining why this version was chosen.
Add a docstring explaining the version selection:
@pytest.fixture(scope="module")
def test_safe(local_web3: Web3, test_keys: APIKeys) -> SafeV141:
+ """Creates a test Safe instance using SafeV141.
+
+ SafeV141 is used because [explain version selection rationale here].
+ """
web3 = local_web3scripts/create_safe_for_agent.py (1)
Line range hint 19-29: Consider enhancing security measures.
While the script is well-structured, consider these security improvements:
- Use environment variables or a secure config file for private keys instead of CLI arguments
- Validate the RPC URL to prevent potential security risks
- Add an upper limit validation for
fund_amount_xdaito prevent accidental large transfers
Here's a suggested implementation:
def validate_rpc_url(url: str) -> bool:
"""Validate RPC URL against allowed patterns/domains."""
allowed_domains = ['gnosis.io', 'infura.io'] # Add your allowed domains
from urllib.parse import urlparse
parsed = urlparse(url)
return any(domain in parsed.netloc for domain in allowed_domains)
def create_safe_for_agent(
from_private_key: str = typer.Option(None, help="Private key (prefer using AGENT_PRIVATE_KEY env var)"),
rpc_url: str | None = None,
salt_nonce: int | None = None,
fund_safe: bool = True,
fund_amount_xdai: int = typer.Option(1, max=10, help="Amount to fund (max 10 xDAI)"),
) -> None:
"""Create and optionally fund a Safe for an agent.
Private key can be provided via AGENT_PRIVATE_KEY environment variable (recommended)
or --from-private-key option (less secure).
"""
from_private_key = from_private_key or os.getenv('AGENT_PRIVATE_KEY')
if not from_private_key:
raise ValueError("Private key must be provided via AGENT_PRIVATE_KEY env var or --from-private-key option")
if rpc_url and not validate_rpc_url(rpc_url):
raise ValueError("Invalid or disallowed RPC URL")tests_integration_with_local_chain/safe/test_safe.py (1)
50-50: LGTM! Consider enhancing test documentation.
The type annotation change to SafeV141 is correct. The test provides comprehensive coverage of safe contract interactions.
Consider adding a docstring to better document the test's purpose and the complex interaction flow with the Omen market:
def test_send_function_on_contract_tx_using_safe(
local_ethereum_client: EthereumClient,
local_web3: Web3,
test_keys: APIKeys,
test_safe: SafeV141,
) -> None:
"""
Tests the safe's ability to execute contract transactions with Omen market.
Verifies:
1. Safe funding with xDAI
2. Market liquidity requirements
3. Token balance changes after transaction
"""prediction_market_agent_tooling/config.py (1)
203-203: LGTM! Consider documenting the SafeV141 version requirement.
The change to SafeV141 is correct and aligns with the migration to safe-eth-py. Consider adding a comment or documentation note about the minimum required version of safe-eth-py to help future maintainers.
Add a comment above the class to document the version requirement:
# Requires safe-eth-py >= 6.0.0b41 for SafeV141 support📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
poetry.lockis excluded by!**/*.lock,!**/*.lockpyproject.tomlis excluded by!**/*.toml
📒 Files selected for processing (10)
- prediction_market_agent_tooling/config.py (2 hunks)
- prediction_market_agent_tooling/deploy/agent.py (2 hunks)
- prediction_market_agent_tooling/tools/safe.py (2 hunks)
- prediction_market_agent_tooling/tools/web3_utils.py (2 hunks)
- scripts/create_safe_for_agent.py (1 hunks)
- tests_integration_with_local_chain/conftest.py (1 hunks)
- tests_integration_with_local_chain/markets/omen/test_omen.py (0 hunks)
- tests_integration_with_local_chain/safe/conftest.py (3 hunks)
- tests_integration_with_local_chain/safe/test_erc20_transfer_using_safe.py (1 hunks)
- tests_integration_with_local_chain/safe/test_safe.py (3 hunks)
💤 Files with no reviewable changes (1)
- tests_integration_with_local_chain/markets/omen/test_omen.py
🚧 Files skipped from review as they are similar to previous changes (1)
- prediction_market_agent_tooling/tools/web3_utils.py
🔇 Additional comments (14)
tests_integration_with_local_chain/safe/conftest.py (3)
17-17: Type safety improvement with explicit version
The return type change from Safe to SafeV141 improves type safety by being explicit about the Safe contract version being used.
35-35: Verify SafeV141 compatibility
The instantiation has been updated to use SafeV141. While this is correct, we should ensure this version is compatible with your deployment environment.
Let's check for version-specific dependencies or configurations:
#!/bin/bash
# Look for SafeV141-specific configurations or version requirements
rg "SafeV141" -A 5 "requirements*.txt"
rg "SafeV141" "setup.py"
rg "safe.*version|SAFE.*VERSION" --type yaml3-4: LGTM! Migration from gnosis.eth to safe_eth
The import changes reflect a clean migration to the new safe_eth library.
Let's verify this migration is consistent across the codebase:
✅ Verification successful
Migration from gnosis.eth to safe_eth is complete and consistent
The verification shows that:
- All relevant files consistently use
safe_ethimports - No remaining
gnosis.ethimports were found SafeV141is consistently used across the codebase in:- Test configurations and tests
- Core tooling and configuration files
- Web3 utilities
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining gnosis.eth imports that might need updating
rg "from gnosis\.eth"
# Verify the new imports are used consistently
rg "from safe_eth\.eth import EthereumClient"
rg "from safe_eth\.safe\.safe import SafeV141"
Length of output: 309
Script:
#!/bin/bash
# Let's try a more comprehensive search for both old and new patterns
# Check for any remaining gnosis.eth imports
rg -l "gnosis\.eth"
# Check for safe_eth imports
rg -l "safe_eth"
# Look specifically for Safe/SafeV141 usage
rg -l "SafeV141"
rg -l "from.*Safe import Safe"
# Check Python files in the test directory for context
fd -e py -p "**/test*/**"
Length of output: 1063
Script:
#!/bin/bash
# Let's examine the content of files that use SafeV141 to verify consistent migration
# Check the content of files using SafeV141
rg "from.*safe_eth" -A 2 tests_integration_with_local_chain/safe/conftest.py
rg "from.*safe_eth" -A 2 tests_integration_with_local_chain/safe/test_safe.py
rg "from.*safe_eth" -A 2 prediction_market_agent_tooling/config.py
rg "from.*safe_eth" -A 2 prediction_market_agent_tooling/tools/safe.py
rg "from.*safe_eth" -A 2 prediction_market_agent_tooling/tools/web3_utils.py
# Check for any remaining old Safe imports or usage
rg "from.*gnosis\.eth.*Safe" -A 2
rg "Safe\(" -A 1
Length of output: 1146
scripts/create_safe_for_agent.py (1)
7-7: LGTM! Verify API compatibility with safe_eth.
The import change aligns with the codebase-wide migration from gnosis to safe_eth library.
Let's verify that the EthereumClient maintains the same interface:
✅ Verification successful
Import change is safe and consistent with codebase-wide migration
The verification confirms:
- The
EthereumClientAPI is consistently used across the codebase with the same interface patterns (get_balance, is_contract, get_network, etc.) - The migration from
gnosistosafe_ethis thorough, with multiple files already using the new imports - No remaining
gnosis.ethimports found, only references to Gnosis documentation and RPC URLs - The
safe_ethlibrary is well-integrated across test and production code with consistent usage patterns
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify EthereumClient usage and interface compatibility
# Test 1: Check for any additional EthereumClient imports that might need updating
rg -l 'from gnosis\.eth import.*EthereumClient'
# Test 2: Compare method usage patterns between old and new implementations
rg -A 2 'EthereumClient\('
Length of output: 1438
Script:
#!/bin/bash
# Let's check the actual usage patterns of EthereumClient to verify API compatibility
# Check EthereumClient method calls in both old and new implementations
rg -A 3 'ethereum_client\.'
# Check imports to see if we missed any files still using gnosis
rg 'from.*gnosis'
# Look for any Safe-related imports to understand the migration context
rg 'from.*safe_eth.*import'
Length of output: 8973
tests_integration_with_local_chain/safe/test_erc20_transfer_using_safe.py (2)
Line range hint 15-69: Test implementation looks robust and comprehensive.
The test function thoroughly validates the ERC20 token operations with Safe contract, including:
- Token deposits
- Transfers to/from Safe
- Approval mechanisms
- Balance verifications
- Withdrawal functionality
The unchanged test implementation suggests that the safe_eth.Safe class maintains API compatibility with the previous gnosis.safe.Safe class.
3-3: Verify Safe class compatibility across the codebase.
The change from gnosis.safe to safe_eth.safe appears to be part of a broader migration. Let's verify that this change is consistent across the codebase and that the new Safe class maintains API compatibility.
✅ Verification successful
Let me gather more information about the Safe class usage to better understand the migration and API compatibility.
Let me check the dependencies and any other Safe-related implementations to ensure we have a complete picture.
Import change from gnosis.safe to safe_eth.safe is correct and consistent
The migration from gnosis.safe to safe_eth.safe is verified to be correct based on the following evidence:
- The project explicitly depends on
safe-eth-py = "^6.0.0b41"in pyproject.toml - No remaining references to
gnosis.safewere found in the codebase - The Safe implementation in
tools/safe.pyconsistently uses the newsafe_ethimports - The test file's usage of Safe class matches the API provided by
safe-eth-py
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent usage of safe_eth.safe across the codebase
# and check for any remaining gnosis.safe imports that might have been missed.
echo "Checking for any remaining gnosis.safe imports..."
rg "from gnosis.safe import"
echo "Verifying consistent safe_eth.safe usage..."
rg "from safe_eth.safe import"
echo "Looking for potential Safe class usage patterns to verify API compatibility..."
ast-grep --pattern 'Safe($$$)'
Length of output: 574
Script:
#!/bin/bash
# Let's examine the actual usage of Safe class in the test file
echo "Checking Safe class usage in the test file:"
cat tests_integration_with_local_chain/safe/test_erc20_transfer_using_safe.py
# Let's also check for any other files that might be using Safe
echo -e "\nChecking for other Safe class references:"
rg "Safe\." -A 2
# Look for potential configuration or setup files
echo -e "\nChecking for potential requirements or dependency files:"
fd "requirements|setup.py|pyproject.toml"
Length of output: 3791
Script:
#!/bin/bash
# Check pyproject.toml for dependencies
echo "Checking dependencies in pyproject.toml:"
cat pyproject.toml
# Check Safe implementation in the tools
echo -e "\nChecking Safe implementation in tools:"
cat prediction_market_agent_tooling/tools/safe.py
# Look for test fixtures that might be using Safe
echo -e "\nChecking for test fixtures:"
rg "def test_safe" -A 3
Length of output: 7970
tests_integration_with_local_chain/conftest.py (2)
Line range hint 47-48: Review EthereumClient initialization.
The local_ethereum_client fixture creates an empty EthereumClient() instance without passing the web3 instance from the dependency. This might cause issues if the client requires initialization parameters.
#!/bin/bash
# Description: Check the EthereumClient usage pattern in tests and implementation
# Check EthereumClient initialization patterns
ast-grep --pattern 'EthereumClient($$$)'
# Check if there are any test files using this fixture
rg -A 3 "local_ethereum_client"Consider updating the initialization to:
@pytest.fixture(scope="module")
def local_ethereum_client(local_web3: Web3) -> EthereumClient:
- return EthereumClient()
+ return EthereumClient(local_web3)10-10: Verify the safe-eth library migration across the codebase.
The import change from gnosis.eth to safe_eth.eth looks good, but let's ensure all related imports are consistently updated.
✅ Verification successful
Migration from gnosis.eth to safe_eth.eth is complete and consistent
The verification shows that:
- No remaining
gnosis.ethimports exist in the codebase - All
safe_eth.ethimports are consistently used across the test files and main codebase - The
EthereumClientis properly initialized with URI parameters in production code, while test fixtures use empty constructors which is a valid testing pattern
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining gnosis.eth imports that might have been missed
# and verify the new safe_eth.eth imports are used consistently.
echo "Checking for any remaining gnosis.eth imports..."
rg "from gnosis.eth import"
echo "Verifying safe_eth.eth usage..."
rg "from safe_eth.eth import"
Length of output: 4076
Script:
#!/bin/bash
# Let's check for both import patterns and actual usage to get a complete picture
# Check for any remaining gnosis.eth imports across the codebase
echo "=== Checking gnosis.eth imports ==="
rg "from gnosis\." -A 1
# Check for safe_eth imports across the codebase
echo -e "\n=== Checking safe_eth imports ==="
rg "from safe_eth\." -A 1
# Check EthereumClient initialization patterns
echo -e "\n=== Checking EthereumClient initialization patterns ==="
ast-grep --pattern 'EthereumClient($$$)'
Length of output: 2856
tests_integration_with_local_chain/safe/test_safe.py (2)
34-34: LGTM! Type annotation correctly updated.
The type annotation change to SafeV141 aligns well with the version assertion in the test.
3-4: Verify safe_eth version requirements.
The migration from gnosis.eth to safe_eth library is a significant change. Please ensure that the project's dependency requirements are updated accordingly.
✅ Verification successful
Dependencies are properly specified with safe_eth_py version 6.0.0b41
The migration from gnosis.eth to safe_eth is properly handled in the project. The poetry.lock file shows that safe_eth_py version 6.0.0b41 is specified as a dependency, and the imports are consistently used across multiple files in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if requirements.txt or setup.py exists and contains safe_eth
fd -e txt -e py -x grep -l "safe_eth" {} \;
Length of output: 461
Script:
#!/bin/bash
# Check for dependency specifications in setup.py or requirements files
fd "setup.py|requirements" -x cat {} \;
# Check for safe_eth imports and their usage patterns
rg "safe_eth" -A 2 -B 2
Length of output: 4217
prediction_market_agent_tooling/tools/safe.py (1)
9-13: Verify safe_eth migration completeness.
The imports have been correctly updated to use safe_eth. However, as noted in previous reviews, several other files still need to be updated for consistency.
✅ Verification successful
Migration to safe_eth is complete and consistent
The verification shows that:
- No remaining
gnosisimports were found in the key files safe_ethis consistently used across the codebase including:- Configuration (
config.py) - Tools (
web3_utils.py) - Scripts (
create_safe_for_agent.py) - Tests (
tests_integration_with_local_chain/safe/*)
- Configuration (
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for remaining gnosis imports and verify safe_eth adoption
# Expected: No gnosis imports in updated files, consistent safe_eth usage
# Check for any remaining gnosis imports
echo "Checking for remaining gnosis imports in key files..."
rg "from gnosis\.|import gnosis" \
"prediction_market_agent_tooling/config.py" \
"prediction_market_agent_tooling/tools/web3_utils.py" \
"scripts/create_safe_for_agent.py" \
"tests_integration_with_local_chain/safe/"
# Verify safe_eth adoption
echo "Verifying safe_eth adoption..."
rg "from safe_eth\.|import safe_eth" \
"prediction_market_agent_tooling/config.py" \
"prediction_market_agent_tooling/tools/web3_utils.py" \
"scripts/create_safe_for_agent.py" \
"tests_integration_with_local_chain/safe/"
Length of output: 1401
prediction_market_agent_tooling/config.py (1)
6-7: Verify consistent usage of safe_eth imports across the codebase.
The imports have been correctly updated from gnosis to safe_eth. Let's verify that this change has been applied consistently across all files.
✅ Verification successful
All gnosis imports have been successfully replaced with safe_eth
The verification shows:
- No direct imports from
gnosispackage remain in the Python files - The only remaining references to "gnosis" are in test comments pointing to documentation
safe_ethimports are consistently used across the codebase in relevant files
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining gnosis imports that need to be updated
echo "Checking for remaining gnosis imports..."
rg "from gnosis\." --type py
echo -e "\nChecking for gnosis package usage..."
rg "gnosis\." --type py
echo -e "\nVerifying safe_eth imports are used..."
rg "from safe_eth\." --type py
Length of output: 2041
prediction_market_agent_tooling/deploy/agent.py (2)
282-282: LGTM! Good addition of the configurable limit.
The new class variable n_markets_to_fetch with a default value of MAX_AVAILABLE_MARKETS is well-placed and properly typed.
380-380: 🛠️ Refactor suggestion
Consider removing the limit parameter from the method signature.
As suggested in the previous review, it would be better to remove the limit parameter from the method signature and always use self.n_markets_to_fetch. This would make the configuration more consistent and prevent potential confusion from having two ways to set the limit.
Apply this change to the method signature and its usage:
def get_markets(
self,
market_type: MarketType,
sort_by: SortBy = SortBy.CLOSING_SOONEST,
filter_by: FilterBy = FilterBy.OPEN,
- limit: int | None = None,
) -> t.Sequence[AgentMarket]:
cls = market_type.market_class
# Fetch the soonest closing markets to choose from
available_markets = cls.get_binary_markets(
limit=self.n_markets_to_fetch, sort_by=sort_by, filter_by=filter_by
)
return available_markets
| @@ -200,6 +200,6 @@ def check_if_is_safe_owner(self, ethereum_client: EthereumClient) -> bool: | |||
| if not self.SAFE_ADDRESS: | |||
| raise ValueError("Cannot check ownership if safe_address is not defined.") | |||
|
|
|||
| s = Safe(self.SAFE_ADDRESS, ethereum_client) # type: ignore[abstract] | |||
| s = SafeV141(self.SAFE_ADDRESS, ethereum_client) | |||
There was a problem hiding this comment.
What is the reason for using SafeV141 instead of just Safe? Is it safe ( 😁 )? Safe in a sense that what if the agent is using different version of it?
There was a problem hiding this comment.
mypy complains because Safe is an abstract class.
SafeV141 is the latest version , and the one we create for all our agents (
…n_markets_to_fetch
No description provided.