I give it a try on the test servers and have some questions:

When are users going to be asked for the captcha on the test environment? How is it similar different from what happens in real wikis with the captcha?

For the test servers, asking every time can get a bit in the way of testing some of the workflows, and we may want to consider options that allow us to try the captcha when needed but not necessarily every time.

In addition, I tried to publish a translation with the following text "hahahahahahahahahahahahaha", which should trigger the "repeated characters" abuse filter defined in T192524. However, I was getting the error captcha as if I had not filled the captcha correctly. I'm not sure if this is related to the configuration, or something for @Petar.petkovic to take a look since he worked on the captcha code.

In T193114#4171193, @Pginer-WMF wrote:

I give it a try on the test servers and have some questions:

When are users going to be asked for the captcha on the test environment? How is it similar different from what happens in real wikis with the captcha?

I told @KartikMistry to set strict rules for captcha, so the dialog is always shown. Since T189766 is now closed, I would say to keep strict rules for another week and then change the ConfirmEdit config to something that resembles some real wiki.

In addition, I tried to publish a translation with the following text "hahahahahahahahahahahahaha", which should trigger the "repeated characters" abuse filter defined in T192524. However, I was getting the error captcha as if I had not filled the captcha correctly. I'm not sure if this is related to the configuration, or something for @Petar.petkovic to take a look since he worked on the captcha code.

Entering correct captcha which doesn't work the first time happened to me before.
I have tried what you described in cx2-testing, to publish page with "hahahahahahahahahahahahaha" as text. Watching server requests and responses, CX side seems good. Server replies with error, like wrong captcha text is entered, so dialog is displayed again.
After that, I tried same workflow with different article and it worked the first time. I suspect something fishy in ConfirmEdit (CAPTCHA extension).

That is one more reason to always show captcha dialog for a little while, so bad behavior can be detected.

@Petar.petkovic Can you paster error happens with Captcha + AbuseFilter? Edit captcha (enabled every time) seems OK to me.

In T193114#4173526, @KartikMistry wrote:

@Petar.petkovic Can you paster error happens with Captcha + AbuseFilter? Edit captcha (enabled every time) seems OK to me.

There is no error logged in console. Just unusual behavior.

In T193114#4173243, @Petar.petkovic wrote:

In T193114#4171193, @Pginer-WMF wrote:

I give it a try on the test servers and have some questions:

When are users going to be asked for the captcha on the test environment? How is it similar different from what happens in real wikis with the captcha?

I told @KartikMistry to set strict rules for captcha, so the dialog is always shown. Since T189766 is now closed, I would say to keep strict rules for another week and then change the ConfirmEdit config to something that resembles some real wiki.

That makes sense. Do you know which are the usual rules that are followed on real wikis for this? Are those based on the number of edits of the user, whether they have solved the captcha before or something else?

In addition, I tried to publish a translation with the following text "hahahahahahahahahahahahaha", which should trigger the "repeated characters" abuse filter defined in T192524. However, I was getting the error captcha as if I had not filled the captcha correctly. I'm not sure if this is related to the configuration, or something for @Petar.petkovic to take a look since he worked on the captcha code.

Entering correct captcha which doesn't work the first time happened to me before.
I have tried what you described in cx2-testing, to publish page with "hahahahahahahahahahahahaha" as text. Watching server requests and responses, CX side seems good. Server replies with error, like wrong captcha text is entered, so dialog is displayed again.
After that, I tried same workflow with different article and it worked the first time. I suspect something fishy in ConfirmEdit (CAPTCHA extension).

When reproducing the error, I noticed that the issue happens when "hahahahahahahahahahahahaha" is added at the end of a paragraph in a new line. I was not getting the error when adding it right after an existing sentence (I guess the abuse filter regex was not catching it in this situation).

As @Nikerabbit pointed out in another conversation, T151116 may be related to this. So we may want to keep an eye on that ticket.