matchers are called for every message when using @app.message

[caddac]

When adding a matcher to @app.message handlers, matchers are called before middlewares, including the middleware that checks for the keyword in @app.message. This means the matcher is called for every message in the channel. In my case, my matcher is going to do several network calls, and I don't want to do that for messages that don't contain the keyword.

I do think I can work around this by using a middleware rather than a matcher, but a matcher seems to perfectly fit my use case.

Reproducible in:

1.11.1 of bolt (and probably prior versions)

Steps to reproduce:

Using the most basic app configuration, setup a matcher and message event handler as below:

def not_brennan(message, logger, client):
    """
    For now, a matcher to filter out brennan by ID
    soon, this will get the users email, and check if a user is in the gcp group
    """
    user = message.get('user')
    logger.info(f'user: {user}')

    email = get_email(client=client, user_id=user)
    logger.info(f'email: {email}')
    # TODO: see if this email address is in a certain GCP group

    if user != "U02RK1ZMZSM":
        return True
    return False


@app.message(":wave:", matchers=[not_brennan])
def wave(say, message, logger):
    user = message['user']
    logger.info(f"message object: {message}")
    say(f"Hi there, <@{user}>!")

Expected result:

The matcher function should only be called for messages that contain :wave:

(Tell what you expected to happen)

Actual result:

The matcher function is called for every single message typed in the channel. This is because the keyword for the message function is added as the first middleware, but matchers are called before middlewares. Here:

bolt-python/slack_bolt/app/app.py

Line 814 in 8cf6087

middleware.insert(0, MessageListenerMatches(keyword))

(Tell what actually happened with logs, screenshots)
You can see I messaged random, then :wave: and the bot responded (slack and logs). I would not expect the 2nd log message checking not_brennan for the message "random"

[misscoded]

Hi @caddac! Thanks for surfacing this and for providing details around your use case. We agree that it's entirely reasonable to expect the filtering of the keyword condition to occur before the matcher.

We'll add this issue to the list of enhancements to be introduced in a coming release.