-
Notifications
You must be signed in to change notification settings - Fork 7
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
Fix challenging agents (replicator, challenger) #510
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,7 +59,7 @@ def resolve_finalized_markets(self, api_keys: APIKeys) -> list[HexAddress]: | |
market | ||
for market in OmenSubgraphHandler().get_omen_binary_markets( | ||
limit=None, | ||
finalized_before=utcnow(), | ||
question_finalized_before=utcnow(), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💡 Codebase verification Inconsistent parameter naming in The 🔗 Analysis chainApprove the parameter name change and verify consistency. The change from To ensure consistency across the codebase, please run the following script: This will help confirm that the 🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Verify the usage of 'question_finalized_before' parameter in OmenSubgraphHandler
# Test: Search for OmenSubgraphHandler class definition and its method calls
rg --type python -A 10 'class OmenSubgraphHandler'
rg --type python 'OmenSubgraphHandler\(\)\.get_omen_binary_markets'
Length of output: 184 Script: #!/bin/bash
# Description: Verify the usage of 'question_finalized_before' parameter in OmenSubgraphHandler
# Test: Search for OmenSubgraphHandler class definition and its method calls
rg --type py -A 10 'class OmenSubgraphHandler'
rg --type py 'OmenSubgraphHandler\(\)\.get_omen_binary_markets'
Length of output: 1431 Script: #!/bin/bash
# Description: Verify the usage of 'question_finalized_before' parameter in all calls to 'get_omen_binary_markets'
# Search for 'get_omen_binary_markets' method calls with 'question_finalized_before' parameter
rg --type py 'get_omen_binary_markets\([^)]*question_finalized_before='
Length of output: 73 |
||
resolved=False, | ||
) | ||
if market.id not in IGNORED_FOR_RESOLUTION | ||
|
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 didn't realise before that if I use
question_finalized_after
, it won't include questions without any answer at all (where it'snull
)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.
Effectivelly what you are doing with the
partial
is an OR filter, since you want (in this code snippet) the questions that finalize afternow() + 30min
OR questions without answers.For this, I find querying the subgraph using
OR
a lot cleaner - see code snippet below (example query).What do you think?
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.
It is clean in the simple example query you provided, but how do you suggest integrating
or
functionality into OmenSubgraphHandler? With any integration that I can imagine, it's in the end easier to just do it like I do it here.finalized_after
shouldn't befinalized_after OR without_answers
, because sometimes we might need to really query onlyfinalized_after
marketsfinalize_after_or_null
filter, because that we would have to haveor_null
variant of many other arguments as wellThere 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 agree
partial
here is simple and works, but what I was thinking is something along these lines (inside the subgraph handler) if the use case becomes more complicated:The added benefit here is to execute just 1 query, whereas in yours we execute 2 queries.
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.
But happy here with partial :)
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.
That will need some fancy refactoring of OmenSubgraphHandler, but I agree it could be nice!
I'm not sure how it would end up in the end, but if you are up to exploring it, it sounds good to me.
That's a good benefit out of it.