-
Notifications
You must be signed in to change notification settings - Fork 265
Open
Description
Description
Currently SignalClient has a complex system of caching received signals:
status-go/tests-functional/clients/signals.py
Lines 77 to 90 in b968bf4
| self.received_signals = { | |
| # For each signal type, store: | |
| # - list of received signals | |
| # - expected received event delta count (resets to 1 after each wait_for_event call) | |
| # - expected received event count | |
| # - a function that takes the received signal as an argument and returns True if the signal is accepted (counted) or discarded | |
| signal: { | |
| "received": [], | |
| "delta_count": 1, | |
| "expected_count": 1, | |
| "accept_fn": None, | |
| } | |
| for signal in SignalType | |
| } |
In most cases, we expect signals in response to some RPC. And sometimes the signal is received while we are still processing the blocking RPC.
Therefore we mix 2 approaches in tests:
- waiting for a signal after making an action
- prepare for signal before the action and check it after the action
And this makes the code very complicated (yet not super reliable).
Proposal
Refactor the thing. SImplify it.
Use with
I would love to see us using with here, smth like this:
def test_foo(backend_new_profile):
sender = backend_new_profile()
receiver = backend_new_profile()
with receiver.expect_signal(SignalType.MESSAGES_NEW, timeout=30):
message_text = "Hello, World!"
sender.wakuext_service.send_one_to_one_message(receiver.public_key, message_text)Though I'm not sure if it will be usable in all cases, we should analyze this carefully first.
Metadata
Metadata
Assignees
Labels
No labels