Uniformize spam-checker API, part 5: expand other spam-checker callbacks to return Tuple[Codes, dict]#13044
Conversation
…cks to return Tuple[Codes, dict]
c8affa5 to
e714f8d
Compare
|
As far as I can tell, the monolith test fails because of a network issue (cannot assign IP), unrelated to the PR. |
|
For some reason, |
…spam to return a Tuple[Codes, dict]?
Tuple[Codes, dict]
babolivier
left a comment
There was a problem hiding this comment.
Sorry about the round-trip time for this one!
tests/rest/client/test_rooms.py
Outdated
| channel = self.make_request("PUT", path, content) | ||
| self.assertEqual(200, channel.code, msg=channel.result["body"]) | ||
|
|
||
| def test_spam_checker_check_event_for_spam(self) -> None: |
There was a problem hiding this comment.
It looks to me like this test could be simplified a lot by using parameterized.expand, see
synapse/tests/http/test_proxyagent.py
Lines 56 to 208 in 339c391
or
synapse/tests/app/test_openid_listener.py
Lines 42 to 79 in 5a15377
for examples.
There was a problem hiding this comment.
So, introduce a new framework to this test along with magic code generation to get rid of one loop?
I can do that if you insist, but my first impression is that this would actually increase cognitive load of reading that test.
There was a problem hiding this comment.
What do you mean by introducing a new framework? We already use it quite a bit in Synapse's tests suite. In my opinion it makes tests much easier to read as it reduces the complexity of the actual test code.
There was a problem hiding this comment.
I mean that reading this test doesn't require understanding that framework yet. If you wish me to introduce it, I can do that, of course.
There was a problem hiding this comment.
Well, your wish is my command :)
babolivier
left a comment
There was a problem hiding this comment.
This plus I really think we should be using parameterized in test_spam_checker_check_event_for_spam.
The objective of this push is to progressively expand the spam-checker API into letting spam-checkers provide reasons for which an event/operation has been rejected. In particular, we wish to prototype account suspension (by opposition to account removal) through spam-checkers and let users know what they need to do to have the account unsuspended.
Specifically, letting a spam-checker return an additional
dictgives us a way to point users towards an individual url on which they can read up all the details about their suspension.This is a followup to:
Codeenum. #12703, Uniformize spam-checker API, part 1: turningCodesinto anEnum.check_event_for_spamto let callbacks returnCodes.check_event_for_spamto let callbacks return additional fields.Union[Allow, Codes]. #12857, Uniformize spam-checker API, part 4: convert other spam-checker callbacks to returnCodes.Pull Request Checklist
EventStoretoEventWorkerStore.".code blocks.(run the linters)