When a user rejects an image, we log the rejection reasons in the instrumentation. The schema definition describes this in more detail. I've confirmed using recent (July 2024) event data that we capture this. Event data is then kept for 90 days.

In T314149#9976442, @Urbanecm_WMF wrote:

This kind of happened – we proxy beta to production GrowthExperiments API AFAIK.

This kind of happened – we proxy beta to production GrowthExperiments API AFAIK.

Marked Gerrit repo as read-only/archived. Thanks everyone!

The error stopped at Jun 3, 2024 @ 09:24:03.218 (it was 1.43.0-wmf.7, no records for wmf.8`) - the logstash link.

Everything is done except marking the gerrit repo as archived, as that needs a gerrit admin.

Change #1039796 merged by Jforrester:

[mediawiki/services/image-suggestion-api@master] Empty repo, being archived

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

Change #1039796 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/services/image-suggestion-api@master] Empty repo, being archived

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

Change #1038807 merged by jenkins-bot:

[integration/config@master] jjb: Drop image-suggestion-api jobs, now unused

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

Filled T366534: Archive mediawiki/services/image-suggestion-api to archive the repository instead; it is no longer necessary.

Since I fixed the reported issue, moving this to sprint and QA.

I tried making a couple of changes using the Special:EditGrowthConfig form at test2.wikipedia.org (which does not have Add Image or section images enabled), and I did not manage to remove the image-related configuration. Maybe this was a bug in EditGrowthConfig that we fixed before? Or maybe I'm not trying to reproduce the bug correctly.

Thanks for filling the task! This comes from the Add an Image feature, which is exposed in two places: Special:Homepage and Wikipedia's mobile phone app. Those two places are independent on each other, which means that Special:Homepage might not offer Add Image, but the mobile app might (or vice versa). The mobile app does use Growth's APIs for identifying the recommendations, and for informing us about decision made by the app users (this avoids the same recommendation being made both in Homepage and the app).

dancy merged https://gitlab.wikimedia.org/repos/releng/blubber/-/merge_requests/86

jforrester opened https://gitlab.wikimedia.org/repos/releng/blubber/-/merge_requests/86

This was for the prototype service, which has been superseded by a permanent solution. This task is therefore no longer relevant.