How to prevent retry of `message` event when matcher returned False?

[yanghua-ola]

My message event handler was configured with a few matchers message_processors.

app.message(jane_message, message_processors)(handle_command)

When one of the matcher return False, the event would be considered unhandled.

INFO:slack_bolt.AsyncApp:Unsuccessful Bolt execution result (status: 404, body: {"error": "unhandled request"})

As a result, the message would be delivered a few more times with retry_reason as timeout.

DEBUG:slack_bolt.AsyncApp:Received message (type: TEXT, data: {"envelope_id":"5e7b873f-8260-499a-94ce-64c877e95df8","payload": ***, "type":"events_api","accepts_response_payload":false,"retry_attempt":3,"retry_reason":"timeout"}, extra: , session: s_8744028994636)

In my case, this resulted error messages being emitted multiple times by one of the matchers.

My desired behavior is one error message for one rejected message, what's the correct way to achieve that?

Reproducible in:

The slack_bolt version

slack_bolt==1.20.0

Python runtime version

Python 3.10.12

OS info

#80-Ubuntu SMP Mon May 15 15:18:26 UTC 2023

Steps to reproduce:

(Share the commands to run, source code, and project settings (e.g., setup.py))

1. Setup a message handler with one matcher that emits a message say("foo") and returns False
2. Trigger the handler by sending a message in the appropriate channel
3. The bot would send multiple foo messages to the channel.

Expected result:

One error message for one rejected message (Matcher returned false)

Actual result:

Error messages being sent repetitively for one rejected message due to retry logic.

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[seratch]

Hi, thanks for asking the question. My reply at #977 (comment) may be helpful for you too.

[github-actions]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

[lyuyangh]

Thanks @seratch for that workaround!

I experienced something similar and the impact was bigger so I would like to add my experience to the conversation. In my case, the number of events that the bot missed was large enough for Slack to turn off event subscription. It was difficult to investigate because I don't have much information on why event subscription was turned off. And the only notification I got were emails while the events are repeatedly turned off.

To elaborate a bit more on my thoughts:

1. I think any event that reaches the listeners in the app should be considered delivered/handled.
   1. It is unintuitive for events to be considered "unhandled" (404) if they are intentionally filtered out by the matchers. I think it is common for developers to want to ignore certain events and that is why matcher is available as a mechanism. I can't think of a situation where it would be useful to have Slack retry the events if they are filtered out by a matcher. With the current design, it means that developer should always register a catch all listener to ack events that fall through.
   2. Alternatively, could we add the catch all listener by default to the library?
2. Would it make sense to have raise_error_for_unhandled_request=True by default because not acknowledging events can have severe consequences?

[github-actions]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

[github-actions]

As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number.