slack/notify is not working in v4.14.0

[s-sasaki-0529]

Orb version:

v4.14.0

What happened:

Slack notifications are not being sent from version v4.14.0. The same configuration works perfectly in v4.13.3, but after upgrading to v4.14.0, no notifications are being sent to Slack.

  slack-notify-sample:
    resource_class: medium
    docker:
      - image: cimg/node:20.17.0
    steps:
      - slack/notify:
          channel: 'XXXXXX'
          event: 'pass'
          custom: |
            {
              "blocks": [
                {
                  "type": "section",
                  "fields": [
                    {
                      "type": "plain_text",
                      "text": "*Tests finished.*",
                      "emoji": true
                    }
                  ]
                }
              ]
            }

The workflow completes without errors, but the notification does not appear in Slack. Instead, the following message is displayed in the job execution results:

NO SLACK ALERT

Current reference "" does not match any matching parameter
Current matching pattern: .+

Expected behavior:

Slack notifications should be sent successfully as they were in v4.13.3. The upgrade to v4.14.0 should not affect the notification delivery.

Additional Information:

I found a potentially related pull request: #459. However, I am not sure why this change would affect the behavior I'm seeing.

[slknijnenburg]

We're running into this issue as well.

We have a workflow that gets triggered via an API request to https://circleci.com/api/v2/project/gh/org-name/repo-name/pipeline, where, upon successful execution of the pipeline we previously (on v4.13.3) got a Slack notification triggered via:

      - slack/notify:
          branch_pattern: main
          event: pass
          channel: '#notifications'
          template: basic_success_1

This now leads to this warning:

NO SLACK ALERT

Current reference "" does not match any matching parameter
Current matching pattern: .+

I'm pretty sure is related to the change in behavior in FilterBy from https://github.com/CircleCI-Public/slack-orb/pull/459/files. By removing the removing the check on the second parameter in FilterBy, the FilterBy will always check the tag on line 219:

        FilterBy "$SLACK_PARAM_TAGPATTERN" "${CIRCLE_TAG:-}"

If there's no tag available, this will lead to an exit 0 in FilterBy. This means it's currently not possible to trigger Slack notifications for any branch-related workflows.

[lkappeler]

Update: Same as ⬆️

We face the same issue. My understanding is that removing the guard for an empty string breaks the default behaviour that was in place before the change.

If the branch matches the next check will be against $CIRCLE_TAG https://github.com/CircleCI-Public/slack-orb/blob/5be0c44dd3532100b5de71da559cbc06f93b4802/src/scripts/notify.sh#L219 (defaulted to an empty string) The issue is the default matcher .+ will not match an empty string and the notification will exit

[marboledacci]

It looks like the problem here is having a default pattern for tag and branch. The default pattern doesn't make sense because that way it will always try to compare with the given reference, even a non existing one, as in the problem you're facing. Not having a pattern should be consider as send, so I will be removing the default.

[marboledacci]

@s-sasaki-0529 Your case seems different to the others, it is reading the event value as fail instead of pass. There is only one way to get to your message and it is not related to the filterBy function. Could you please show what your output is in the previous step.

[s-sasaki-0529]

@marboledacci Thank you for your response. I realized that the output message I provided was incorrect. The correct output message is:

NO SLACK ALERT

Current reference "" does not match any matching parameter
Current matching pattern: .+

It seems that I mistakenly provided the output from a simplified workflow I constructed for reproduction purposes, which resulted in a different message being displayed than the one in the original case. Therefore, I believe my issue is the same as the others.

[marboledacci]

This should be now fixed on version v5.0.0