Bump PMAT and small niches #548
Conversation
WalkthroughThis pull request includes changes to several files, primarily focusing on updating the import statements for the logger from 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 (
|
|
I will merge this PR as hotifx for our agents, because there are too many connections to the database. This PR is uncontroversial (just PMAT bump mostly), but I'll leave gnosis/prediction-market-agent-tooling#547 open for a proper review and after that, I'll open a new PR here to switch to the proper (non-dev) version of PMAT. |
![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 (2)
prediction_market_agent/agents/microchain_agent/blockchain/contract_class_converter.py (2)
Line range hint
156-158: Consider enhancing the "from" keyword replacement logic.The current approach of replacing "from" with "sender" might be fragile if the contract's ABI uses these terms inconsistently or if "from" appears as part of another word.
Consider using a more robust approach:
- if "from" in function_code: - function_code = function_code.replace("from", "sender") + import re + function_code = re.sub(r'\bfrom\b', 'sender', function_code)
Line range hint
102-112: Enhance type mapping error messages.The warning messages for type mapping failures could be more informative by including the actual type that failed.
Consider enhancing the error messages:
- logger.warning( - f"Type mapping for {abi_item.name} has failed. Check inputs {abi_item.inputs}" - ) + logger.warning( + f"Type mapping for function '{abi_item.name}' failed. Unsupported input type: {input.type}. " + f"Available types: {list(TYPE_MAPPING.keys())}" + )
📜 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 (3)
prediction_market_agent/agents/microchain_agent/blockchain/contract_class_converter.py(1 hunks)prediction_market_agent/db/pinecone_handler.py(1 hunks)prediction_market_agent/run_agent.py(0 hunks)
💤 Files with no reviewable changes (1)
- prediction_market_agent/run_agent.py
✅ Files skipped from review due to trivial changes (1)
- prediction_market_agent/db/pinecone_handler.py
🔇 Additional comments (2)
prediction_market_agent/agents/microchain_agent/blockchain/contract_class_converter.py (2)
9-9: LGTM! Verify logger interface compatibility.
The change to use the custom logger from prediction_market_agent_tooling.loggers aligns with the standardization effort across the codebase.
Let's verify that the custom logger provides the same interface as loguru for the warning level:
✅ Verification successful
Import change is consistent with codebase-wide pattern
The change to use prediction_market_agent_tooling.loggers is verified to be part of a consistent pattern across the entire codebase, with 28+ files using the same import. The file contains two logger.warning calls that follow this standardized approach.
Reasoning:
- The search results show widespread adoption of
from prediction_market_agent_tooling.loggers import loggeracross multiple components - This change aligns the file with the project's standardized logging approach
- The presence of
logger.warningcalls in the file confirms active usage of the logger interface
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the custom logger interface matches loguru's interface
# Test 1: Check the custom logger implementation
rg -A 5 "class.*Logger" prediction_market_agent_tooling/loggers
# Test 2: Verify all warning calls are compatible
rg "logger\.warning" prediction_market_agent_tooling/
Length of output: 274
Script:
#!/bin/bash
# Let's try searching in the current repository
# Check if the logger module exists and its implementation
fd "loggers?.py$"
# Check the usage of logger.warning in the current file
rg "logger\.warning" prediction_market_agent/agents/microchain_agent/blockchain/contract_class_converter.py
# Look for other logger imports to understand the pattern
rg "from.*logger.*import"
Length of output: 3597
Line range hint 144-146: Review exec() usage for security implications.
The use of exec() for dynamic function creation could be dangerous if the input is not properly sanitized. While the current usage appears safe as it's working with validated ABI data, it's worth documenting this security consideration.
Let's verify the ABI validation:
✅ Verification successful
Exec usage is properly secured through validated ABI data
The exec() usage is safe because:
- Input is validated through Pydantic's BaseModel (ABIMetadata, ArgMetadata)
- The function code is constructed using strictly controlled components:
- Function name from validated ABI
- Arguments from validated ArgMetadata
- Fixed template strings for view/payable functions
- Namespace is isolated with only the contract reference
- Python reserved keywords (e.g., "from") are properly handled
- The generated code only calls contract.call() or contract.send() with validated parameters
The security concern is adequately addressed through the validation chain and controlled code generation process.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for ABI validation before exec
# Test: Look for validation of ABI items
rg -B 5 "exec\(" .
rg "model_validate|validate" prediction_market_agent/agents/microchain_agent/blockchain/
Length of output: 1158
Script:
#!/bin/bash
# Let's check the ABIMetadata class definition and validation
ast-grep --pattern 'class ABIMetadata'
# Also check the function that generates the code being exec'd
ast-grep --pattern 'def create_function_code'
# And check how the namespace is prepared
rg -B 5 "namespace = {" .
Length of output: 206
Script:
#!/bin/bash
# Let's check the ABIMetadata class definition and validation with proper escaping
rg -A 10 "class ABIMetadata" .
# Check the function that generates the code being exec'd
rg -A 10 "def create_function_code" .
# And check how the namespace is prepared with proper escaping
rg -B 5 "namespace = \{" .
Length of output: 1508
Script:
#!/bin/bash
# Let's check the full context of where exec is used and how the function code is created
rg -B 20 -A 10 "exec\(" prediction_market_agent/agents/microchain_agent/blockchain/contract_class_converter.py
# Also check the ArgMetadata definition since it's part of the validation
rg -A 5 "class ArgMetadata" .
# And check the AbiItemTypeEnum and AbiItemStateMutabilityEnum
rg -A 5 "class AbiItem.*Enum" .
Length of output: 3022
No description provided.