Unblocked: directly load the logo detection model within the same code.

Blocked by T364551#9977031.

Thanks @kevinbazira for the prompt action. @klausman @isarantopoulos , as we're now entering hypothesis work under time constraints, could you please give us an estimate to tackle this request?
The LiftWing endpoint being accessible is a hard requirement for T368624: [XL] Post-upload job to detect logos. CC @AUgolnikova-WMF .

@matthiasmullie wrote:

Hi @kevinbazira; we finally have an API in production that is supposed to send data to the logo detection service at https://inference-staging.svc.codfw.wmnet:30443/v1/models/logo-detection:predict
It doesn’t fully seem to work, though - it looks like some servers are able to access that uri, while others are not.
E.g.:

curl -H 'X-Wikimedia-Debug: backend=mwdebug1001.eqiad.wmnet' https://commons.wikimedia.org/w/api.php\?action\=mediadetection\&format\=json\&formatversion\=2\&filekey\=1b2a8gxjr6m0.xox7qj.6750701.jpg
{"predictions":[{"filename":"1b2a8gxjr6m0.xox7qj.6750701.jpg","target":"logo","prediction":0.0035,"out_of_domain":0.9965}]}

but:

curl -H 'X-Wikimedia-Debug: backend=k8s-mwdebug' https://commons.wikimedia.org/w/api.php\?action\=mediadetection\&format\=json\&formatversion\=2\&filekey\=1b2a8gxjr6m0.xox7qj.6750701.jpg
{"error":{"code":"http-timed-out","info":"HTTP request timed out.","docref":"See https://commons.wikimedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."},"servedby":"mw-debug.eqiad.pinkunicorn-b74f6b749-d6pc6"}

We suspect that that internal endpoint is not available to mw k8s nodes - do you know how to make them accessible?

Also done with https://gitlab.wikimedia.org/repos/structured-data/image-suggestions/-/merge_requests/39 and https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags/-/merge_requests/583.
@matthiasmullie the floor is back to you.

• change section topics DAG's default data quality scripts output

A note that we should tackle this.

Actually partially addressed, see T369053#9962162.

In T369053#9958572, @Etonkovidova wrote:

The good candidate (in my opinion) for such change would be a message that should appear for a pre-filled date from EXIF . (per the not-yet-done spec in T362328):

BTW @matthiasmullie I've just downloaded the patch, and this message doesn't show up anymore.

In T362328#9961872, @Sneha wrote:

@mfossati I am moving this back to doing as we have one AC missing

@Sneha I think this will be addressed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UploadWizard/+/1051758, is that right @matthiasmullie ?

Pasting the conclusion here for convenience.

Other edit tags

PAWS

No deletions due to logo except a negligible 0.002 % on Feb 2024.

Results

Upload Wizard

In T368624#9943707, @Cparle wrote:

• have a script running continuously somewhere (on toolforge?) listening to MW events

References:

• https://wikitech.wikimedia.org/wiki/Event_Platform/EventStreams_HTTP_Service
• https://stream.wikimedia.org/?doc#/streams

https://gitlab.wikimedia.org/repos/structured-data/section-topics/-/merge_requests/29 reviewed, looks great to me.

@Etonkovidova @Sneha FYI as of now the patch is reverted, so we won't see the change on beta until we re-merge it.

@Etonkovidova @Sneha , the reason why I haven't added that horizontal line is because another one will show up in case of multiple uploads, so I've left it out.

Hey @KStoller-WMF , chiming in while @AUgolnikova-WMF is out of office: yes, I'll pick up this ticket next week. Stay tuned!

In T363506#9794241, @isarantopoulos wrote:

We concluded that we will figure out the format after the team figures out the spike (accessing the image and sending a thumbnail to Lift Wing).

See T364551: [SPIKE] Send an image thumbnail to the logo detection service within Upload Wizard

I'd suggest we proceed with a base64 encoded image for now.

With binary being the preferred format, right?

In T362749#9786269, @isarantopoulos wrote:

In T362749#9786161, @Ladsgroup wrote:

Yes, Upload stash shouldn't be accessed directly or indirectly. It is internal to mediawiki and private.

Having it private makes total sense from a user privacy point of view. This would also mean that sending image thumbnails from the stash to Lift Wing is out of the question.

I think that the logo detection service can be exposed through an internal endpoint, so it will be inside WMF’s infrastructure.
Moreover, when an image is sent to the upload stash, there’s a set of already implemented checks including existing duplicates and previously deleted duplicates.

In T362749#9789915, @Ladsgroup wrote:

you can just send over the file to liftwing maybe? (we should consider alternative designs and so on).

See T363506: Pass image objects to the logo detection service.

In T362749#9785333, @isarantopoulos wrote:

@mfossati is there any other way to access the images in the upload stash other than using a cookie. Using a user cookie to access an API doesn't seem like the right way for a production application both from a design as well as a security point of view. An API key/token would seem more appropriate (if there is such an option available).

I agree and have dug deeper in the current request being made to the Upload API: maybe the CSRF token is what we're looking for. See upload_file_in_chunks in the example request code. I can confirm that the Upload Wizard is sending a token parameter in the request.

In T361049#9784859, @Etonkovidova wrote:

(2) I have some problems testing these two AC:

• Pre-fill the title using file name if it matches the descriptive criteria, if not leave it blank
• Update the copy for the current error message for when the user has not entered a descriptive title as show here.

In T361049#9784859, @Etonkovidova wrote:

(1) the scope of re-designing Describe step presently doesn't include Additional information from the figma mockup

Chiming in: this will be done in T361061: [M] Update the 'other information' field in upload wizard.

In T363506#9757394, @isarantopoulos wrote:

@mfossati I am in favor of passing the image object in some serialized form.
We would need the upload wizard to send a resized image (224x224) instead of the whole file.

I've opened T364551: [SPIKE] Send an image thumbnail to the logo detection service within Upload Wizard to investigate the feasibility of this solution.

In T363506#9781491, @mfossati wrote:

In T363506#9781301, @isarantopoulos wrote:

@mfossati We noticed that the user can define the width in the url like in this example http://commons.wikimedia.org/w/index.php?title=Special:FilePath&file=Cambia_logo.png&width=224. If we can use this then it would be sufficient and we can stick with using urls in the request.

Hmm, I've just given it a try and I think it won't work for stashed images, which is a hard requirement for us.

@isarantopoulos @kevinbazira , I think I found how to get a thumbnail from a stashed image. There you go: https://commons.wikimedia.org/wiki/Special:UploadStash/thumb/1awuam969hko.2tkfbz.10893556.png/224px-1awuam969hko.2tkfbz.10893556.png, where 1awuam969hko.2tkfbz.10893556.png is the stash file key. The 224px- prefix is the width size.
Of course, I feel there's a caveat, as it seems that the thumbnail is generated on the fly at request time. Still not optimal, but sounds like a workable solution.

In T363506#9757394, @isarantopoulos wrote:

We would need the upload wizard to send a resized image (224x224) instead of the whole file.

I can imagine we can tackle that from within the Upload Wizard with some JavaScript library. I can create a ticket to look into that if you think this would be the best solution.

In T363506#9780991, @kevinbazira wrote:

If one user sends a request with 50 image URLs and another sends a request with 50 serialized images objects, the latter is likely to exceed the server's request body size limit faster.

Thinking out loud: what about sending multiple requests if the limit is reached? I speculate that 50 uploads are an edge case: if this happens, we could dispatch different requests.

In T363506#9781301, @isarantopoulos wrote:

@mfossati We noticed that the user can define the width in the url like in this example http://commons.wikimedia.org/w/index.php?title=Special:FilePath&file=Cambia_logo.png&width=224. If we can use this then it would be sufficient and we can stick with using urls in the request.

Hmm, I've just given it a try and I think it won't work for stashed images, which is a hard requirement for us.

@isarantopoulos , totally agree, makes a lot of sense.