Page MenuHomePhabricator

Second edits to an entry on ISA are not being saved
Open, Needs TriagePublicBUG REPORT

Assigned To
None
Authored By
Anthere
Jun 9 2023, 3:17 PM
Referenced Files
F37149831: photo 4.png
Jul 26 2023, 12:22 AM
F37149832: photo 3.png
Jul 26 2023, 12:22 AM
F37149833: photo 1.png
Jul 26 2023, 12:22 AM
F37149834: photo 2.png
Jul 26 2023, 12:22 AM

Description

Steps to replicate the issue (include links if applicable):

  • I used by default campaign https://isa.toolforge.org/campaigns/244
  • I get to an entry and make a first change (in this case, a depict). I click save. I get the green message on the ISA tool confirming the modification is saved. When I go to Commons, I see my edit was saved
  • I stay on the SAME entry, and I make a second modification (I tested once depict and once caption and the result was identical). After making my modification on ISA, I click save.

What happens?:

  • On ISA, I get the green message telling me the second modification was saved
  • However, on Commons... no modification is done. No contribution is recorded.

Repeated several times. Also tested on another campaign. In all cases, only the first modification was actually saved.

What should have happened instead?:

  • All modifications (depicts or captions) should have been saved

Event Timeline

Critical bug which does not raise any interest ?

Sebastian will have to dig in to the logs but it sounds like the locally stored metadata is not being updated when the first edit is saved, so when attempting to save a second time Commons complains that the edits are being added from the incorrect starting point.

I see two separat bugs here:

  1. The edit isn't saved
  2. The failure message from Commons is not reflected in the message shown to the ISA user.

The response from /api/post-contribution/ is "Failure", both the first time, when an edit is made on Commons, and second time, when it's not. However, this is counted as a success by the javascript because the status is 200; that the string says "Failure" doesn't matter. This value is then used as a revision id for the next request to Commons, which is probably what's causing the issue.

This seems to be caused by the same issue as in T340485. I tried on the code with the fix for that and it worked, both edits were saved.

Change 937895 had a related patch set uploaded (by Sebastian Berlin (WMSE); author: Sebastian Berlin (WMSE)):

[labs/tools/Isa@m2c-rollback] Update usage of isa.main.utils.commit_changes_to_db()

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

Change 937895 merged by jenkins-bot:

[labs/tools/Isa@m2c-rollback] Update usage of isa.main.utils.commit_changes_to_db()

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

Sebastian, I just tested this several times on https://isa.toolforge.org (my understanding is that this would have been fixed)
This bug is still ongoing.
It does not make a difference that the change is a depict or a rank. The first change is saved, the following changes to the same images are not taken into account (nor in the edit counter on ISA, nor on Commons). But we still get the green message saying that the modification was saved

I tried just now and I managed to make three separate depicts saves in a row. They were all recorded both in ISA and on Commons.

@Anthere, can you write down the exact steps you took to trigger the bug? Include campaign, image and the statements added.

It looks like there is something going on with the function in the backend that does the saving. It's possibly related, or at least similar, to T342553: Saving prominence change causes subsequent saves to silently fail.

I also just tested it and managed multiple saves in a row. Following the. Make an editsaveawait confirmationmake a new editsaveawait confirmation.

I tried both depicts and descriptions.

@Sebastian_Berlin-WMSE Are there any frontend changes where one might need to force the cached .js (in the browser) to clear?

Mentioned in SAL (#wikimedia-cloud) [2023-07-25T07:40:46Z] <wm-bot> <sebastian-berlin-wmse> Deployed from scratch. Changes from previously deployed version: bdf632a Pin required package versions; 471967f Update usage of isa.main.utils.commit_changes_to_db() (T340485, T338624); cf008eb Add semi automatic script for deploying on Toolforge; 0b135aa Use Celery for background jobs (T340485).

@Sebastian_Berlin-WMSE Are there any frontend changes where one might need to force the cached .js (in the browser) to clear?

I don't think there were any frontend changes that would've caused this, but it never hurts to try.

I think I got the pattern.
I followed the same strategy twice with slight difference, and in both cases, the result was the same... the info stopped being recorded.

So here is the two situations

Situation 1
I add a depict. I save. Change appears on Commons.
I add a second depict. I save. Change appears on Commons
I add a caption. I save. Change appears on Commons
I toggl the importance. I save. Change does not appear
I add a new depict. I save. Changes does not appear

Example : https://commons.wikimedia.org/w/index.php?title=File:French_School_(18)_-_Madame_de_Lamballe.png&action=history

Situation 2
I add a depict. I save. Change appears on Commons.
I add a second depict. I save. Change appears on Commons
I toggl the importance up. I save. Change does not appear
I add a new depict. I save. Changes does not appear
I toggl the importance down. I save. Change does not appear

Example : https://commons.wikimedia.org/w/index.php?title=File:Fig12Femme_normale_avec_le_corsetGaches-Sarraute.jpg&action=history

This is aligned from my previous tests. Common element is that the modifications (any modification to depict, toggle, caption) done AFTER a change of importance is done, stop being saved. The toggle is not saved either.
As long as you edit without changing the importance level of the depict... all goes well. Asap you change the importance... nothing gets saved any more.

It is slightly different to https://phabricator.wikimedia.org/T342553
Which suggest that the first prominence change is recorded on Commons. If you consider that the initial addition of a depict, by default at « low importance » counts as first, then yes, the first is recorded, and the second actually fails (in spite of message)
But if you do not count « creation » as a « modification », then the very first modification fails

photo 2.png (810×1 px, 234 KB)

photo 1.png (599×1 px, 198 KB)

photo 3.png (810×1 px, 138 KB)

photo 4.png (778×1 px, 353 KB)

It is slightly different to https://phabricator.wikimedia.org/T342553
Which suggest that the first prominence change is recorded on Commons. If you consider that the initial addition of a depict, by default at « low importance » counts as first, then yes, the first is recorded, and the second actually fails (in spite of message)
But if you do not count « creation » as a « modification », then the very first modification fails

It's different, but it still seems like prominence changes play a part. I wouldn't be surprised if both bugs are caused by the same underlying issue.