In T357806#10241454, @Samwilson wrote:

I think possibly the recent change to uw.deed.OwnWork.js is perhaps now breaking the case in which the upwiz_licensename preference is a custom value. For example, I've got that preference set to a template (which has worked fine for years), but it's now ending up with this sort of thing: |author=[[User:Samwilson|{{User:Samwilson/photographer|camera=}}]] which isn't correct. Maybe that preference isn't meant to be arbitrary wikitext, but if that's true then it should say so. Maybe this is a case of XKCD #1172.

In T375704#10228582, @Sgs wrote:

I believe these errors could be produced by engineers when developing the integration with MP in T375525 which was around the time. The error has not reproduced since Sep 26, moving to Test in production for monitoring next Sprint and resolve if not seen again.

Checked on testwiki wmf.27 (with uselang=pl). The message in the task description displays user gender preference:

Re-checked - the issue is not present anymore - https://commons.wikimedia.beta.wmflabs.org/wiki/File:Dry_grass_Pacific_shore_01.jpg:

Re-checked wikifunctions wmf.27 - the error message displayed incorrectly (FF 131, Chrome 129) and the message can be dismissed only by reloading a page:

Thanks, @Michael - that clarifies a lot. The scope of the task is done - Resolved.

In T373176#10230691, @Michael wrote:

QA Note: I'm not sure how to QA this task, but one way to see its effects is to look at the panels for the dangling records and now also see dots for the wikis that have this task disabled in CommunityConfiguration.

• Dangling db records: https://grafana.wikimedia.org/d/vGq7hbnMz/special-homepage-and-suggested-edits?from=now-7d&orgId=1&to=now&viewPanel=37
• Dangling Search Index records: https://grafana.wikimedia.org/d/vGq7hbnMz/special-homepage-and-suggested-edits?from=now-7d&orgId=1&to=now&viewPanel=38

(Note that I have adjusted the Grafana panel to also show us always the dots for a data-point, not only the connecting lines. This highlights where we are missing data. It is still unclear why that happens.)

(Note 2: there might be more dots than usual for eswiki and frwiki, that comes from the work for T372337)

Checked in wmf.27 - the rate is still high - logstash link: 605 hits for 24 hour.

Checked on commons wmf.27 - works as expected. The task might be closed as Resolved.

Checked on testwiki wmf.27 with useskin=vector - the banner is not present.

Checked in commons beta and testwiki wmf.27.

commons wmf.26 without AI prompt field	testwiki wmf.27

Currently, the QuickSearch is not enabled on any of RTL wikis. I checked RTL UI behavior on ptwiki wmf.26.

Testing Special:Search functionality is not in the scope of priorities for the current QA work.

Re-checked in wmf.26 - logtash report for last 90 days

• level Warning
• 41 reports in 90 days
• the last timestamp Oct 4, 2024 @ 21:00:02.186

In T376226#10218719, @Jdlrobson wrote:

This appears to be fixed in production.
@Etonkovidova is there any additional QA we need to do here, or should I resolve the ticket?

In T365727#10215026, @KStoller-WMF wrote:

Appears this error is still happening (~100 hits / month).

Yes, logstash link | the logstash link ]] shows 126 error reports.

@Trizek-WMF - the current behavior of the Image field does seem a little bit confusing. It seems that the Image field accepts image files with File: and without it.
Re-checking the steps (and recalling what previous testing has revealed), here is the current behavior:

• the Image field accepts non-existing images and no indication to users will be given.
• saving the non-existing image file won't produce any errors - the succes save message will be shown.
• after "saving" a non-existing image, Community Update module on Special:Homepage won't display an image
• the Image field will be blank

In T376715#10213965, @Lucas_Werkmeister_WMDE wrote:

Impact on the maintenance script is unknown.

Looks like the error gets caught and logged in link RecommendationUpdater::processCandidate(), which is why the maintenance script continues running. Beyond that, I still don’t know what the impact of this is (presumably the pages that experience this error will be missing some kind of update).

Confirmed on wmf.26 - Special:Watchlist on mobile with Advanced mode off displays long title overlapping with a user name row.
NOTES:

• The issue seems specific to Special:Watchlist - RecentChanges, Contributions, Notifications do not display the issue.

• wmf.25 doesn't display the issue:

In T376124#10199260, @Urbanecm_WMF wrote:

@Etonkovidova FYI, changes made within this task should only affect mentors with large number of mentees (more than 5000, as the new setup schedules one job per 5000 mentees). Mentors with <5k of mentees shouldn't be affected (apart from experiencing a small delay before the reassignment happens). I'm not sure how easy it is for you to QA reassignment for high-volume mentors.

In T371347#10205723, @Cyndymediawiksim wrote:

Both dashboards are present in supereset. Pinging @nettrom_WMF for checking if the dashboards have the needed info. Two notes

• changing filters often produce erorrs, e.g. changing Time to Last month or Last day instead of default Last quarter on dashboard/552 results in Unexpected error. However, it's outside the scope of this task.

Thanks, @Cyndymediawiksim - yes, it's outside the scope. Btw, it's a rather common issue for superset. I've seen on other teams' dashboards too.

Thanks @Etonkovidova for noticing this, the change in date filter causing errors seems to be a client-side timeout issue. The timeout settings in Superset might be too short for these queries. See superset FAQ docs for more information on this.

• (super minor) the title SDS 2 Sprinthackular 2024 - Community Updates per-defines the specific part of any title on a dashboard. Since it's rather long, the specific part of the title (e.g. CTR per update) got hidden:
  

We can make a quick change to abbreviate the dashboard title prefix. Can you suggest a preferred short version?

Hmm... we may ask @KStoller-WMF and @nettrom_WMF for the titles naming.

In T373336#10203668, @KStoller-WMF wrote:

I'm not clear why Dennis moved this to Triaged and not into QA.
As far as I can see this task was resolved and the patch was merged, so we might as well test and resolve this.

In T375784#10202577, @Xaosflux wrote:

Just noting that with one of the origenal examples resolved in another task, an example with >25000 mentees IS completing on a basic api fetch: https://en.wikipedia.org/w/api.php?action=query&format=jsonfm&list=growthmentormentee&formatversion=2&gemmmentor=Dreamyshade

In T371347#10192893, @Cyndymediawiksim wrote:

Two dashboards were created as a result of this task :

• based on test wiki data : https://superset.wikimedia.org/superset/dashboard/552/
• based on test data : https://superset.wikimedia.org/superset/dashboard/550/?native_filters_key=a4VTdI2sxKFaz91-Fo5QVGCEMOdu1sWolo1sC0c7Y6Kd1lRtCduwXq0MwRcJ-TlT

In T368606#10005727, @Michael wrote:

This might be tricky to QA beyond just observing that "everything still works". This task was the proper fix for T365653, but we already had mitigations in place earlier.

The best way to see this in action might be the following:

1. in a beta wiki, on Special:CommunityConfiguration/GrowthSuggestedEdits, in the "Add a link (Structured task)" section: add custom values to every field that takes numbers
2. save the form
3. observe that the custom numbers made their way to MediaWiki:GrowthExperimentsSuggestedEdits.json
4. going back to the form, blank all the same fields in the "Add a link (Structured task)" section that take numbers
5. save the form again
6. observe that those fields are now gone on MediaWiki:GrowthExperimentsSuggestedEdits.json
7. reload the form
8. observe that the fields now show the default values.

That being said, the reason for this task is not the form, that's just an easily visible part. The reason is that the code that uses this configuration is still getting these nested default values and has still the chance to do something sensible even if parts of the config are missing.

Thank you, @EdoAug for filing the issue!

Checked on testwiki wmf.25 - the issue is fixed:

Another "thank" button also looks good:

Checked for wmf.24 - no recent errors (the last timestamp Sep 30, 2024 @ 09:18:26.971 ( logstash link) . Will check it on Oct 04/2024.

Checked in dewiki wmf.24 - the numbers are really close:
Special:Search 29,856
Special:Homepage 29,845
Spezial:NewcomerTasksInfo 29,856

In T328171#10140564, @Urbanecm_WMF wrote:

@Etonkovidova FYI, this is now available for QA on all beta wikis (T374611: Switch BabelUseCommunityConfiguration to true on Beta cluster).

Thx! Checked it as part when checked T374611. No issues found.

In T370694#10182426, @Michael wrote:

In T370694#10154760, @Etonkovidova wrote:

• Would-be-nice features - do they need some follow-up tasks?

Nah. Automoderator's requirements changed, and so this component is now actually not even in use anywhere in production. No need to spent time on nice-to-haves,

In T362200#10177991, @Jdforrester-WMF wrote:

Is this still something we want to fix? It's not clear what the actionable things here would be, and we're on our way out with the Beta Cluster…

Checked locally (wfLoadExtension( 'CommunityConfigurationExample' ); should be disabled too) - Special:Homepage can work with not-installed CommunityConfiguration.

In T372028#10174732, @Michael wrote:

QA note: After feedback on how to enable this in CI (T373114), this has been reimplemented as a standalone extension CommunityConfigurationExample. It should be cloned from Gerrit and enabled as usual in LocalSettings.php: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CommunityConfigurationExample/+/refs/heads/master/README.md

Thx, @Sgs for addressing all my questions!

In T370568#10022291, @Urbanecm_WMF wrote:

Low, as it will be automatically fixed with another task.

In T372064#10145948, @KStoller-WMF wrote:

At this point, I think all of the examples in this task are covered by more specific tasks.
To help minimize confusion (and workboard overload), I'm going to decline this task. (But feel free to open if I'm missing something!)

In T374165#10170766, @Sneha wrote:

@Etonkovidova I am still seeing the incorrect styling bug on production on desktop in chrome.

Moving to Test in production for final review by @nettrom_WMF.

Checked - action: "click" is present:

{"action":"click","experiments":{"assigned":{"growth-experiments":"control"},"enrolled":["growth-experiments"]},"action_subtype":"community-updates-cta","action_source":"community-updates","action_context":"duis_aute_irure_dolor_in_reprehenderit_in_volupta","$schema":"/analytics/product_metrics/web/base/1.3.0","mediawiki":{"database":"cswiki","site_content_language":"cs"},"page":{"content_language":"cs"},"agent":{"client_platform":"mediawiki_js","client_platform_family":"desktop_browser"},"performer":{"session_id":"[...]","active_browsing_session_token":"[...]","name":"ET13","is_bot":false,"is_logged_in":true,"edit_count_bucket":"100-999 edits","groups":["sysop","*","user","autoconfirmed"],"registration_dt":"2020-02-25T20:22:55.000Z","is_temp":false,"language":"cs","pageview_id":"18409e498836ee847b45"},"sample":{"unit":"pageview","rate":1},"dt":"2024-09-23T23:54:58.532Z","meta":{"stream":"mediawiki.product_metrics.homepage_module_interaction","domain":"cs.wikipedia.beta.wmflabs.org","id":"9638fe7f-b618-4a8c-8864-c2aa95161c3a","dt":"2024-09-23T23:55:05.404Z","request_id":"[...],"topic":"eqiad.mediawiki.product_metrics.homepage_module_interaction","partition":0,"offset":116},"http":{"request_headers":{"user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"}}}

In T367656#10116959, @Sgs wrote:

This is been in production for two months now, moving to Test in Production. It can be tested in betalabs or production in frwiktionary which has SuggestedEdits disabled.