Disallow configuring filters with both manual and generated topic lists #976
Conversation
de098c7
to
6c6d8f2
28b1a2d
to
7ae8fe3
@pipermerriam This could use another review. I added another bugfix to the topic list construction by removing the permutation of the full topic list by the topic options. Options are passed as lists in place of the bare topic string when multiple topics are to match on one argument. ie:
|
@@ -31,48 +31,46 @@ def hex_and_pad(i): | |||
( | |||
EVENT_1_ABI, | |||
{}, | |||
[[EVENT_1_TOPIC]], |
carver
Jul 30, 2018
Collaborator
This API change doesn't have any downstream effects in the public API?
This API change doesn't have any downstream effects in the public API?
dylanjw
Jul 30, 2018
Author
Contributor
There shouldn't be a bad effect. Because the topic list permutations were removed, construct_event_topics
only needs to return a nested list when there are multiple options for a single argument filter.
There was a bug in how the topic list was being generated. This is an example of a correctly formated topic list to match logs with either of two values for the first indexed event arg:
[ event_sig_topic, [option1_for_arg1, option2_for_arg1], arg2_topic ]
whereas this is what we were generating to be equivalent to the above; we would pass full topic list permutation against each option:
[
[ event_sig_topic, option1_for_arg1, arg2_topic ],
[ event_sig_topic, option1_for_arg1, arg2_topic ]
]
This topic topic list actual means: any of [event_sig_topic, option1_for_arg1, arg2_topic ]
in the first position and any of [event_sig_topic, option1_for_arg1, arg2_topic]
in the second position. Node filters don't understand nested lists as full topic lists. The spec defines a single topic list that can have nested lists of options for each positional element.
There shouldn't be a bad effect. Because the topic list permutations were removed, construct_event_topics
only needs to return a nested list when there are multiple options for a single argument filter.
There was a bug in how the topic list was being generated. This is an example of a correctly formated topic list to match logs with either of two values for the first indexed event arg:
[ event_sig_topic, [option1_for_arg1, option2_for_arg1], arg2_topic ]
whereas this is what we were generating to be equivalent to the above; we would pass full topic list permutation against each option:
[
[ event_sig_topic, option1_for_arg1, arg2_topic ],
[ event_sig_topic, option1_for_arg1, arg2_topic ]
]
This topic topic list actual means: any of [event_sig_topic, option1_for_arg1, arg2_topic ]
in the first position and any of [event_sig_topic, option1_for_arg1, arg2_topic]
in the second position. Node filters don't understand nested lists as full topic lists. The spec defines a single topic list that can have nested lists of options for each positional element.
dylanjw
Jul 30, 2018
Author
Contributor
I can break this part out into another PR, and add a failing test.
This issue has been fixed in the new api: #953. Im fixing this function to make it easier to integrate the new filter builder api.
I can break this part out into another PR, and add a failing test.
This issue has been fixed in the new api: #953. Im fixing this function to make it easier to integrate the new filter builder api.
What was wrong?
Related to Issue #975
How was it fixed?
Only allow configuring log topic filters via the
topics
orargument_filters
parameter and not both.Cute Animal Picture