1. highlighting indeed didn't work either on idwiki or testwiki. I'm not sure how to investigate this but we'd definitely have to look at how highlighting works in recentchanges and see if it is properly configured in the ORES extension for revertrisk
2. Here we have a more standard QA process which we can perform on testwiki. I tried 2 things:
   1. ✅ manual quick pass: went to recentchanges page and clicked on the filter which got me to the last 50 changes over the last 7 days link. This gave 11 results and then looked up all these in the ores_classification table and found that all of them had scores above 0.95 (which is the threshold set on testwiki). This is the list of revision ids I checked: (658519, 658352, 658350, 658337, 658326, 658306, 658290, 658287, 658254, 658121, 658118)
   2. ❌ More thorough investigation. Count the number of revisions that get a score > 0.95 over the last 30 days and double check from the UI. By running the following query I got 50 records while in the UI using this URL I found 44 which indicates that there are some changes not shown in the UI. I just filtered for namespace 0 (main article).

Here is the query found in quarry as well for folks to check if I have missed a filter or something.

SELECT  COUNT(*) from ores_classification  oc
INNER JOIN recentchanges rc on oc.oresc_rev = rc.rc_this_oldid
AND oresc_model=62 -- the revertrisk model id in testwiki ores_model table
AND oc.oresc_probability >= 0.95
AND rc.rc_namespace=0
AND rc.rc_timestamp > rc.rc_timestamp - INTERVAL 30 DAY;

I think it would be useful for us to document thoroughly the investigation during this Spike and use it as a guide for QAing the thresholds as we roll this out

Next steps:

1. Highliting UI issue investigation: @Kgraessle
2. QA on classification issue based on the threshold for idwiki @gkyziridis we think we are good to go.
3. Review all wiki threholds: https://phabricator.wikimedia.org/T392148#10838253 looks good, go for deployment.
4. Deployment of all wikis.......... (probably deploying batches half/half)

In T395256#10857325, @isarantopoulos wrote:

1. highlighting indeed didn't work either on idwiki or testwiki. I'm not sure how to investigate this but we'd definitely have to look at how highlighting works in recentchanges and see if it is properly configured in the ORES extension for revertrisk
2. Here we have a more standard QA process which we can perform on testwiki. I tried 2 things:
   1. ✅ manual quick pass: went to recentchanges page and clicked on the filter which got me to the last 50 changes over the last 7 days link. This gave 11 results and then looked up all these in the ores_classification table and found that all of them had scores above 0.95 (which is the threshold set on testwiki). This is the list of revision ids I checked: (658519, 658352, 658350, 658337, 658326, 658306, 658290, 658287, 658254, 658121, 658118)
   2. ❌ More thorough investigation. Count the number of revisions that get a score > 0.95 over the last 30 days and double check from the UI. By running the following query I got 50 records while in the UI using this URL I found 44 which indicates that there are some changes not shown in the UI. I just filtered for namespace 0 (main article).

Here is the query found in quarry as well for folks to check if I have missed a filter or something.

SELECT  COUNT(*) from ores_classification  oc
INNER JOIN recentchanges rc on oc.oresc_rev = rc.rc_this_oldid
AND oresc_model=62 -- the revertrisk model id in testwiki ores_model table
AND oc.oresc_probability >= 0.95
AND rc.rc_namespace=0
AND rc.rc_timestamp > rc.rc_timestamp - INTERVAL 30 DAY;

I think it would be useful for us to document thoroughly the investigation during this Spike and use it as a guide for QAing the thresholds as we roll this out

I think is this an interesting QA process that we can stabilise. I ran the same query and the count results was 43, and I count one by one the results in the link you provided and the count is same: 43. Which means that the results are consistent.

@isarantopoulos @gkyziridis

Hello, I'm just following up on the highlighting issue after chatting with the team.
We think it's ok to go ahead and deploy to idwiki without fixing the highlighting in the UI.
Apologies for having to do this again; I was just being extra cautious Monday.

Should we try a back-port again for tomorrow or Thursday?
Either day works for me.

After a conversation on slack we have scheduled the deployment for UTC morning backport window https://schedule-deployment.toolforge.org/window/1748415600

@Kgraessle no need to apologize, we collectively took the decision to revert during the deployment. Better safe than sorry!
As per the extra work I just see it as the muscle memory we need to build ;)

rc.rc_timestamp > rc.rc_timestamp - INTERVAL 30 DAY;

This clause makes this a great query (lots of irony) 🤦 This would always be true for really obvious reasons (any timestamp will always be greater than the result of subtracting time from itself) . Sorry about that!

Changing the above query to:

SELECT COUNT(*) from ores_classification  oc
INNER JOIN recentchanges rc on oc.oresc_rev = rc.rc_this_oldid
and oresc_model=2 -- this may vary per wiki
and oc.oresc_probability >= 0.845 -- this may vary per wiki
AND rc.rc_namespace=0
AND rc.rc_timestamp > NOW() - INTERVAL 1 HOUR; -- we can check for 1,2,3 hours depending on the number of edits. Ideally we can first check for 1h, then 2h etc.

then from the UI by selecting only the revertrisk filter and namespace=0 (main page) we can validate that the numbers match

The filter is live on idwiki 🎉
I cross checked during the deployment that the filters work by running the query above and then validating that the same number of revisions are filtered through the UI

I've noticed that a message is not translated and fallbacks to english although a translation already exists in the repo
The translation id is ores-rcfilters-revertrisklanguageagnostic-revertrisk-desc

Actually the same happens with the title of the filter: ores-rcfilters-revertrisklanguageagnostic-title

Change #1151700 had a related patch set uploaded (by Kgraessle; author: Kgraessle):

[mediawiki/extensions/ORES@master] [Spike] Investigate why filtering wasn't working on testwiki

https://gerrit.wikimedia.org/r/1151700

I tried to fix the highlighting issue, but wasn't able to get the ext.ores.highlighter.js file to add the appropriate class to then use for highlighting.
I would love to get some more eyes on it- am I understanding the highlighting correctly?
https://gerrit.wikimedia.org/r/1151700

As far as the translation goes, I see on wiki that the message is falling back to english here:
ores-rcfilters-revertrisklanguageagnostic-revertrisk-desc
ores-rcfilters-revertrisklanguageagnostic-title

Looking at the version currently deployed to idwiki https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/ORES/+/refs/heads/wmf/1.45.0-wmf.2/i18n/id.json it looks like both messages are missing there.
Can we just update them on wiki?

Ok got it. If the MediaWiki train deployment goes through tomorrow we should be able to see the translations as they are part of 1.45.0-wmf.3 and idwiki is running on 1.45.0-wmf.2 (latest commit 19/5 --one day before these messages were added).
I'm not aware if and how we can override translations on wiki.
For the following releases I'd suggest that we prioritize the translations so that they end up in the next train(s). Otherwise we would have to backport the patches that have translations by running the BackportTranslationsScript maintenance script.

In T395256#10864120, @isarantopoulos wrote:

Ok got it. If the MediaWiki train deployment goes through tomorrow we should be able to see the translations as they are part of 1.45.0-wmf.3 and idwiki is running on 1.45.0-wmf.2 (latest commit 19/5 --one day before these messages were added).
I'm not aware if and how we can override translations on wiki.
For the following releases I'd suggest that we prioritize the translations so that they end up in the next train(s). Otherwise we would have to backport the patches that have translations by running the BackportTranslationsScript maintenance script.

Ok, I created a subtask T395481: Ensure all ORES i18n messages are available for wikis to add revert risk language agnostic filters to to capture this work.

Test wiki created on Patch demo by KGraessle-WMF using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/e169d46fa5/w/

Test wiki on Patch demo by KGraessle-WMF using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/e169d46fa5/w/

Ok, I have a patch out that fixes the highlighting issue.
@gkyziridis and @isarantopoulos if you could review it whenever you get a chance. Thanks!

Thanks for tackling that! I tried testing this locally but it didn't work. I was running it MediaWiki+ORES extension in docker. Perhaps I missed sth. I'll also try patchdemo. In any case we'll offer feedback by tomorrow!

Test wiki created on Patch demo by KGraessle-WMF using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/5081d27793/w/

Test wiki on Patch demo by KGraessle-WMF using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/5081d27793/w/

In T395256#10867452, @isarantopoulos wrote:

Thanks for tackling that! I tried testing this locally but it didn't work. I was running it MediaWiki+ORES extension in docker. Perhaps I missed sth. I'll also try patchdemo. In any case we'll offer feedback by tomorrow!

Nope- it was still a bit broken.

I refactored a bit and deleted the javascript module as it wasn't actually where the highlighting class was getting added. It should be fixed now!
I don't believe we can use patch demo because we'd have to set the config to include revert risk language agnostic model/thresholds which doesn't seem possible in the given patchdemo interface.

I have been testing this locally, and I can see the highlighting, however, I found one issue. When the changes list is grouped by page, if there is a highlighted change in the grouping, the parent line is highlighted in grey. I don't see this behavior happening on enwiki. The grey highlighting is happening on light and dark themes, and on both versions of Vector.

Here is a screenshot of Vector 2010

@Scardenasmolinar I did notice that greying out effect, but I saw it both on testwiki and enwiki.

testwiki:

enwiki:

Want me to file a separate bug for this?

Sure, let's do that!

Change #1151700 merged by Scardenasmolinar:

[mediawiki/extensions/ORES@master] Fix highlighting for revertrisklanguageagnostic

https://gerrit.wikimedia.org/r/1151700