Moving back to "Ready" so that we can file a schema change task.

In T410762#11454609, @kostajh wrote:

In T410762#11425344, @BTullis wrote:

It looks like OpenSearch publish their own benchmarking tool: https://docs.opensearch.org/latest/benchmark/quickstart/

We should be able to install it in a conda environment on a stat server, then run it against https://opensearch-test.discovery.wmnet:30443

Updated endpoint is https://opensearch-ipoid.discovery.wmnet:30443/opensearch_ipoid/_search

In T410762#11425344, @BTullis wrote:

It looks like OpenSearch publish their own benchmarking tool: https://docs.opensearch.org/latest/benchmark/quickstart/

We should be able to install it in a conda environment on a stat server, then run it against https://opensearch-test.discovery.wmnet:30443

In T412120#11454221, @kostajh wrote:

In T412120#11454151, @MLechvien-WMF wrote:

More example of bugs I can't access to:

• https://phabricator.wikimedia.org/T401695 eqsin upload issues timeout
• https://phabricator.wikimedia.org/T406119 thumbor overloaded

Those are both filed by @corto -- perhaps we could have a Herald rule that auto-subscribes relevant users? Once you're subscribed, you can view those tasks.

In T412120#11454151, @MLechvien-WMF wrote:

More example of bugs I can't access to:

• https://phabricator.wikimedia.org/T401695 eqsin upload issues timeout
• https://phabricator.wikimedia.org/T406119 thumbor overloaded

Looks like we just need to update onContributionsToolLinks to remove the !IPUtils::isValidRange( $username ) condition, which isn't needed any more since we now support IP range queries on AbuseLog (per T391322)

For example in the mock below, the number "11+" should link to Special:IPContributions for the underlying IP address if there is only one IP connecting all associated temp accounts

In T412222#11449356, @neriah wrote:

Allow me to express my doubts.
If the limits are defined in this way, what will be done regarding public computers? In a single day, dozens of people may use the same computer, and it is not unreasonable that more than two of them want to make some change in wikipedia. Since each one uses a guest browser, the third person who wishes to edit will no longer be able to do so.
Additionally, there could also be an issue on a personal computer for people who use a guest window.

Looks like we need to reuse the same logic from Special:AbuseLog that allows for parsing ranges.

In T412218#11450676, @mszwarc wrote:

• Add "Temporary accounts from all associated IPs" (surfaced in UserInfo card) on:
  • Special:Contributions (temp account)

@Niharika Should this information be gated behind some right? Currently, this number is available only in UIC, so only registered users can see this data. When we embed it onto contributions, it'll be viewable by anyone. Is that okay?

Revised wording (Slack) for WikimediaMessages

Yeah, I don't think this ever took off as a useful developer tool, so I'd +1 removing it.

Bringing to current sprint to see if we can do this quickly.

Proposal from @DLynch:

If you wanted to just duplicate the current getPreSaveProcess methodology with a getSaveOptionsProcess that’s passed saveOptions to modify, that’d probably be most-fitting

Seems like this may still be an issue, so I'm moving it to ready, for investigation and follow-up fixes.

Schema is merged, back to in progress.

Nevermind, @Tgr notes that this is a side effect of T394402: Reduce noisy auth logs

In T411963#11439048, @DatGuy wrote:

Automatically resubmitting any form sounds like a hack at best and a recipe for disaster at worst. Can the captcha not be returned immediately?

T375712#10234942 says

In T411927#11439859, @Xaosflux wrote:

I did a test, the edit just went though - were you able to verify it actually works if the automatic hcaptcha failed?

This should be resolved now, having switched to using 99.9% passive mode on enwiki. hCaptcha will challenge suspicious sessions on edit/create/addurl on the first click to publish changes.

I've also filed T411963: hCaptcha: Automatically resubmit "publish changes" when AbuseFilter's "showcaptcha" trigger is invoked to make the experience in the AbuseFilter "showcaptcha" path more intuitive.

Thanks for filing the task, and sorry for the issues being encountered here. The problem being reported is because we are using 100% passive mode for ConfirmEdit's "edit" trigger, with an "always challenge" mode set for the "addurl" trigger. The "addurl" trigger has always functioned after a page reload. We updated the AbuseFilter "showcaptcha" trigger (which has a similar flow of happening after a page reload) to tell the user that they need to resubmit the form, but we missed doing that for "addurl" when in 100% passive mode

In T406880#11300166, @colewhite wrote:

In T406880#11286467, @kostajh wrote:

@colewhite would you be able to also set up an alert for the Logstash entry for hCaptcha is unavailable, falling back to FancyCaptcha?

From the code, it looks like that log entry hinges on $services->getService( 'HCaptchaEnterpriseHealthChecker' )->isAvailable(): Since we have access to this code, I'd like to propose a change to the ConfirmEdit extension to back this alert.

We will also need a operations/mediawiki-config patch to register this stream, and a patch to Extension:CheckUser to update the instrumentation submission code, as the MetricsPlatform client won't work with this stream (afaik, cc @phuedx)

My mistake, I was looking at null edits (which show the performer of the last edit on the page, which was a bot user).

Another flaky test: editEntityDatatypes.cy.ts, seen on https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-selenium-php83/779/console

In T411263#11423080, @Bugreporter wrote:

These wikis currently have wgAutoConfirmCount set to 0.

This is always the default in MediaWiki (see https://www.mediawiki.org/wiki/Manual:$wgAutoConfirmCount). I believe we should set it to a non-zero value in Wikimedia default and MediaWiki default - which I said before at T323948#9103374. We may need a global RFC for that.