Suggestion: default to not sending event if there is an error in the modules callback

[benparsons]

A developer working on a new project using the modules system reports:

if the module fails for some reason (e.g. with a runtime error in the Python code), the event is let through. This is worrying as it means that we don't have control on what the module can block. Is there a way to turn this around and have the module block the event by default in case of error?

The problem here is clearly that outside of the module interface it's not known which event types needed to be handled by the module. Is there a way we can flag events which have not been handled by the module callback and fail them?

[babolivier]

The problem here is clearly that outside of the module interface it's not known which event types needed to be handled by the module.

It depends on the callback, if you're talking about check_event_for_spam, then the module is expected to handle all events (where by "handle" I also mean drop them for types it's not interested in).

[babolivier]

After discussing this internally it looks like the team's opinion is that we should fail the request if the module encounters an error. However, note that check_event_for_spam currently doesn't have this kind of error handling/protection, so I'm a bit unsure why this is showing up.

[erikjohnston]

Yeah, a quick look at the code suggests if check_event_for_spam fails by raising an exception the event should be rejected. Is that what they mean here?

[DMRobertson]

Is this related to #11031 ?

[benparsons]

@DMRobertson yes, I think O's issue clarifies and replaces my own.

[DMRobertson]

Thanks! Let's close this and continue the discussion there.