-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
469 missing information in ipfsagentresult #521
base: main
Are you sure you want to change the base?
Conversation
…ing-information-in-ipfsagentresult # Conflicts: # prediction_market_agent_tooling/deploy/agent.py
reasoning = ( | ||
processed_market.answer.reasoning | ||
if processed_market.answer.reasoning | ||
else "" | ||
) | ||
agent_result = IPFSAgentResult(reasoning=reasoning, agent_name=self.agent_name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved this logic from OmenAgentMarket -> DeployableTraderAgent because the property agent_name
belongs to DeployableTraderAgent
.
One could simply pass the property as arg, but I would argue that the responsibility to build a IPFSAgentResult should be handled by the agent itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IPFSAgentResult
is specific to Omen; for example, Metaculus wants only a comment without any IPFS upload.
That refactoring was made based on Evan's comment because there were a lot of Omen-uniquess in the DeployableTraderAgent.
Maybe it could be named IPFSOmenAgentResult
or something to make it clearer in the code. 🤔
Wdyt just passing agent_name
into store_prediction
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong preference here - passing agent_name
is fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it could be named IPFSOmenAgentResult or something to make it clearer in the code. 🤔
I would prefer to keep it as IPFSAgentResult
- we can rename it once we have other agents uploading results as well.
Co-authored-by: Peter Jung <peter@jung.ninja>
WalkthroughThe pull request introduces several modifications across multiple files, primarily focusing on enhancing the Changes
Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
prediction_market_agent_tooling/markets/agent_market.py (1)
232-235
: LGTM: Method signature updated correctly.The
store_prediction
method signature has been appropriately updated to include theagent_result
parameter. This change aligns with the PR objectives and maintains the abstract nature of the method.Consider updating the method's docstring to reflect the new
agent_result
parameter and its purpose.prediction_market_agent_tooling/markets/omen/data_models.py (1)
801-801
: LGTM! Consider reordering fields for better readability.The addition of the
agent_name
field is correct and aligns with the PR objectives. However, for better code organization, consider moving theagent_name
field above themodel_config
. This keeps all the fields together and separates them from the configuration.Here's a suggested reordering:
class IPFSAgentResult(BaseModel): reasoning: str - agent_name: str + agent_name: str model_config = ConfigDict( extra="forbid", )
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- prediction_market_agent_tooling/deploy/agent.py (3 hunks)
- prediction_market_agent_tooling/markets/agent_market.py (2 hunks)
- prediction_market_agent_tooling/markets/omen/data_models.py (1 hunks)
- prediction_market_agent_tooling/markets/omen/omen.py (1 hunks)
🧰 Additional context used
🔇 Additional comments (4)
prediction_market_agent_tooling/markets/agent_market.py (1)
22-22
: LGTM: New import statement is correctly placed and follows best practices.The import of
IPFSAgentResult
from the Omen-specific module is appropriate and aligns with the PR objectives.prediction_market_agent_tooling/markets/omen/omen.py (1)
Line range hint
420-438
: LGTM! The changes improve thestore_prediction
method.The updated implementation correctly incorporates the
agent_result
parameter, which now includes theagent_name
as mentioned in the PR objectives. The code is more streamlined by directly using theagent_result
in thestore_agent_result
call, avoiding unnecessary object creation.prediction_market_agent_tooling/deploy/agent.py (2)
338-340
: Addition ofagent_name
property enhances metadata handlingThe
agent_name
property provides a standardized way to access the agent's class name, improving metadata consistency across different agents.
500-508
:⚠️ Potential issueRefactor to remove Omen-specific logic from
DeployableTraderAgent
Creating an
IPFSAgentResult
and using it inafter_process_market
introduces Omen-specific functionality intoDeployableTraderAgent
. This violates the separation of concerns and reduces the agent's applicability to other markets that do not use IPFS, such as Metaculus.As previously suggested, consider the following refactoring:
- Pass
agent_name
as an argument tostore_prediction
, allowing market-specific implementations to handle the result appropriately.- Define an abstract method or hook in
DeployableTraderAgent
for result handling that can be overridden by subclasses or specific market implementations.- Move the creation of
IPFSAgentResult
into the Omen-specific market class to maintain a clean separation between generic agent logic and market-specific details.
@@ -19,6 +19,7 @@ | |||
TokenAmount, | |||
) | |||
from prediction_market_agent_tooling.markets.market_fees import MarketFees | |||
from prediction_market_agent_tooling.markets.omen.data_models import IPFSAgentResult |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Missing IPFSAgentResult Parameter in Subclasses and Method Call
Several areas in the codebase have not been updated to include the IPFSAgentResult
parameter:
-
Subclasses missing
IPFSAgentResult
instore_prediction
:prediction_market_agent_tooling/markets/omen/omen.py
-
Method call missing
IPFSAgentResult
argument:prediction_market_agent_tooling/deploy/agent.py
Please update the store_prediction
methods in the affected subclasses and ensure all calls to store_prediction
include the IPFSAgentResult
parameter.
🔗 Analysis chain
Verify implementation in subclasses and related components.
The changes to the AgentMarket
class, while minimal, have a significant impact on the codebase:
- All subclasses implementing
store_prediction
will need to be updated to handle the newagent_result
parameter. - Any code calling
store_prediction
will need to provide theIPFSAgentResult
argument.
Please run the following script to identify potential areas that need updates:
Ensure that all identified areas are updated to accommodate the new agent_result
parameter.
Also applies to: 232-235
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Identify classes that inherit from AgentMarket and places where store_prediction is called.
# Find subclasses of AgentMarket
echo "Subclasses of AgentMarket:"
rg "class \w+\(.*AgentMarket.*\):" -g '*.py'
# Find calls to store_prediction
echo "\nCalls to store_prediction:"
rg "\.store_prediction\(" -g '*.py'
Length of output: 902
Script:
#!/bin/bash
# Description: Verify that each subclass of AgentMarket has an updated store_prediction method with the IPFSAgentResult parameter.
# List of subclass files
subclasses=(
"prediction_market_agent_tooling/markets/polymarket/polymarket.py"
"prediction_market_agent_tooling/markets/omen/omen.py"
"prediction_market_agent_tooling/markets/metaculus/metaculus.py"
"prediction_market_agent_tooling/jobs/jobs_models.py"
"prediction_market_agent_tooling/jobs/omen/omen_jobs.py"
"prediction_market_agent_tooling/markets/manifold/manifold.py"
)
for file in "${subclasses[@]}"; do
echo "Checking store_prediction method in $file:"
rg "def store_prediction\s*\(" "$file" | while read -r line; do
# Check if the method includes 'IPFSAgentResult' as a parameter
if [[ "$line" =~ store_prediction\([^\)]*IPFSAgentResult[^\)]*\) ]]; then
echo " ✅ Updated store_prediction method found."
else
echo " ❌ store_prediction method missing IPFSAgentResult parameter."
fi
done
done
# Check the call in deploy/agent.py
echo -e "\nChecking store_prediction call in deploy/agent.py:"
rg "\.store_prediction\s*\(" prediction_market_agent_tooling/deploy/agent.py | while read -r line; do
# Check if the call includes 'IPFSAgentResult' argument
if [[ "$line" =~ store_prediction\([^\)]*IPFSAgentResult[^\)]*\) ]]; then
echo " ✅ store_prediction call includes IPFSAgentResult argument."
else
echo " ❌ store_prediction call is missing IPFSAgentResult argument."
fi
done
Length of output: 3078
@@ -48,6 +48,7 @@ | |||
MarketType, | |||
have_bet_on_market_since, | |||
) | |||
from prediction_market_agent_tooling.markets.omen.data_models import IPFSAgentResult |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid importing Omen-specific classes in a generic agent module
Importing IPFSAgentResult
from markets.omen.data_models
introduces Omen-specific dependencies into the generic DeployableAgent
class hierarchy. This reduces modularity and reusability, potentially causing issues for other markets like Metaculus that do not require IPFS uploads.
Consider abstracting the result handling to be market-agnostic. You could define a generic interface or base class for agent results and let market-specific implementations extend it. This way, DeployableTraderAgent
remains decoupled from any specific market logic.
-> Adding agent_name to structure being uploaded to IPFS