Endless builds because of "ignore committer strategy" no longer working as before

[Enrice]

Jenkins and plugins versions report

Environment

Jenkins 2.452.3
ignore-committer-strategy 1.0.4
cloudbees-bitbucket-branch-source 887 or 888 likewise, 886 worked ok

What Operating System are you using (both controller, and any agents involved in the problem)?

Rocky Linux 9

Reproduction steps

add at least 2 commits by the same exempted author and push them at the end of the build.
--- or ---
just trigger a multibranch pipeline scan.

Expected Results

There should be no difference regarding the number of commits; if the push only contains commits of the same exempted author, the build should not be triggered.

Actual Results

With builds that produce 2 commits by our CI user, those get endlessly re-triggered by branch events.
With builds that only produce 1 commit, the strategy works as expected.
When triggered by a scan, ALL branches get rebuilt

Anything else?

No response

Are you interested in contributing a fix?

No response

[nfalco79]

Do you know in which version this worked? I mean, this is only a configuration passed in the API 1.0 used when a web hook for Bitbucket server is created/updated. And only if, in the jenkins configuration page you choose "Webhook implementation to use" Plugin (Post Webhooks for Bitbucket plugin) configuration in place of Native webhook, The plugin is installed on datacenter side through the Altassian Market Place.

This plugin only receive notifications so if the behaviour was changed is bitbucket side. To ensure (this) plugin works as expected could you provide a screen of the web hook configuration server side to verify if the committers to ignore was filled as expected?

[Enrice]

latest working has already been mentioned in "Environment" section above.
This issue may be related to #904, in the sense that rebuilding was occurring anyway.

[nfalco79]

I asked if there was a working version only because seems strange that it works for the first notification but not for the second unless the second one does not contains the expected information to make the filter work as expected.