This is because we're extracting the thresholds incorrectly from the ORES API: the thresholds for "false" qualities need to be inverted.
After discussing this with @Reception123 on IRC and poking around in the code a bit, I suddenly remembered https://gerrit.wikimedia.org/r/#/c/340129/ , which should have fixed this bug. Duped to the task that patch was tagged with.
Interesting. Could you paste the entire error message, with any backtraces and other information that appears alongside it?
Why are you running sql.php and what are you passing to it? Is this part of the extension setup process?
When do you get this error? When running update.php? When viewing a page? When doing something else?
So it looks like filter capsules representing highlights are red if they don't do anything because the filter selection excludes those. For example, if you select "Unregistered" and highlight "Newcomers", the latter is marked red. This makes some sense because the unregistered filter ensures there will be no newcomers in the result. But the tooltips don't explain that. We'll have to figure out what we want the behavior to be here.
Wed, Mar 22
Ahm, why are those even red? Isn't that wrong? @Mooeypoo
These session IDs are not available on the server, but since both the (filter) logging and the beta feature itself are only for logged-in users right now, I'll just log the user ID instead. We can then derive sessions from user IDs and gaps in timestamps.
Tue, Mar 21
This appears to have been caused by rEFLW699c5d86fcea: Fix history pagination and give user the number of entries they requested which made TopKIndex explicitly not match any reverse queries. This breaks a hack whereby order-by-timestamp queries are directed to a special instance of TopKIndex that uses a special storage backend (TopicListLastUpdatedStorage instead of TopicListStorage) which knows to do the join against the workflow table. This worked in forward mode, rEFLW699c5d86fcea: Fix history pagination and give user the number of entries they requested made it so that TopKIndex never matches reverse-ordered queries, so in reverse mode the query wouldn't match any of the indexes, which would throw a NoIndexException, which then gets caught and the query falls back to using the backend storage class directly, but because that is TopicListStorage rather than TopicListLastUpdatedStorage here, it doesn't know to do the join and explodes.
I can reproduce this locally, it looks like it happens whenever api.php?action=flow&submodule=view-topic is invoked with vtloffset-dir=rev.
This happens because Flow tries to access sessionStorage, which throws an exception. The weird Storer module that Flow uses doesn't handle this correctly.
Mon, Mar 20
Oh, yes, sorry, we were proposing eliminating "hard", not "softest", good catch. I got confused because these preferences are named in reverse order. In that case, "hard" is the default on Wikidata and used by more than 200 users, so it's not as unused as I thought it was.
For "Tool usage profile", we already have data on filter usage going back months, and Stephane's got a patch that adds tracking for highlight usage. Re the percentage idea, remember that the percentages would add up to >100% because one selection can include multiple filters.
We discussed the possibility of eliminating the "lowest" preference, as well as the possibility of just pegging it to something other than maybebad. @Ladsgroup / @Halfak can you shed some light on why "lowest" was introduced and what it was calibrated to? T150224 does say fpr=0.1 but I don't know what that means.
Sat, Mar 18
The fix for this bug is scheduled for deployment on Monday March 20 at 13:00-14:00 UTC.
The instance isn't listening on port 22 either, so I decided to just delete it.
(Re Wikidata, it might be simpler to just do T158025?)
I changed "is conflicting with" to "conflicts with" in the result area messages, because from our IRL discussion earlier today I guessed that that's what you meant and that you'd forgotten to update those. Let me know if that's not right.
I looked at doing this, but one issue is that while "lowest" sensitity (0.90) aligns well with "verylikelybad" (0.92), and "low" sensitivity (0.70) aligns well with "likelybad" (0.75), "high" sensitivity (0.50) does not align at all well with "maybebad" (0.16), It's also a bit strange IMO that the maybebad threshold (0.16) is below the likelygood threshold (0.55).
Fri, Mar 17
We found the cause, and Matt came up with a strategy for fixing it that I like.
I have to go run an errand now, but when I get back (in 45-60 mins) I'll look into this.
We can probably make the i18n messages wikitext messages and deliver them to the client as parsed messages in a separate object, but it would be a bit more work.
To clarify, you are talking about the filter capsules, not the list entries, correct?
That's not where that button normally is in GuidedTour dialogs, and Matt was already complaining about the (in his view) excessive overrides of GT's default style.
I think the description also misunderstands the "Hide probably good edits" preference. There are two of them, an RC one and a watchlist one.
I've also found that this happens for hieroglyph nodes too, but not for math and score nodes, even though they're also subclasses of ve.dm.MWExtensionNode. For some reason, any changes to math and score nodes are rendered in the diff as deleting the old node and inserting the new node, whereas changed to syntaxHighlight and hiero nodes are correctly detected as attribute changes.
Thu, Mar 16
This should be fixed now, but observe that "Likely good faith" + "Maybe bad faith" = everything. This is because "Likely good faith" is defined as score> 0.234 and "Maybe bad faith" is defined as score < 0.371. Because the lower bound for "good" is below the upper bound for "maybebad", all changes are either "good" or "maybebad", and some changes are both.
From analyzing the queries, it looks like maybebadfaith is ignored completely (probably because I renamed it from maybebad). Doing just ?goodfaith=maybebadfaith results in no WHERE clause on the score at all, whereas ?goodfaith=good,maybebadfaith and ?goodfaith=good result in the same query. This suggests maybebadfaith is ignored.
Apologies for the long delay in responding.
Wed, Mar 15
That depends on your sensitivity setting.
Tue, Mar 14
Right, I forgot that it was already uploaded. I'll review it soon.
If you're saying that we don't want to offer the highlighting part of classic ORES on the RC page, that seems fine to me, as it's redundant with RCFilters. However, I think we should still keep the newly-default parts of the classic ORES interface on the RC page. That also wouldn't require anything weird preference-wise, because that stuff isn't triggered by preferences.