Content loss after using the web to edit and publish a draft created with the app

[designsimply]

Steps to reproduce:

1. Create and save a draft in the app.
2. Leave the app open to the Blog Posts list.
3. Open the draft on the web, make edits to the title and body, and publish it.
4. In the app, open the post again from the drafts post list.
5. Note that changes from the web aren't synced when it is opened from the drafts post list.
6. Close the post in the app (e.g. in an attempt to back out without saving anything).
7. Check the post on the web to see if the published post is still published (it is).
8. Go to the published posts list, refresh, and open the post from there.
9. Note that only changes to the post title from the web are now synced and changes made to the body of the post are lost.

Result: if a draft made with the app is edited and published on the web, the edits made using the web are not synced in the drafts post list and only the changes to the post title are synced after refreshing the published post list view and opening the post again. Changes made to the body of the post are lost. (3m40s)

Note: I tested with Aztec and the block editor and saw the same result for both.

^{Tested with WPAndroid alpha-177 (12.8 alpha) on Pixel 3 Android 9.}

_{h/t @rachelmcr for the testing steps (internal reference: p4a5px-2pK-p2)}

[designsimply]

Labeling as high priority because of the potential for data loss.

[shiki]

Thank you for the video! That was very helpful.

Changes made to the body of the post are lost.

Following the steps on the video, I'm having trouble reproducing the content loss. I used WPAndroid 12.7.1 and latest develop (badea06). I tried both Aztec and Gutenberg. Would you mind verifying again, @designsimply?

As for the conflict resolution described in p4a5px-2pK-p2, that sounds like a bigger project that requires some upfront design and possibly API changes. I linked to it in #10008 (comment).

[shiki]

Moving this back to Prioritized for now.

[mzorz]

Things I noticed in the video linked above that I found weird:

• after the Post is modified on the web and the screen is refreshed on the mobile side, the card in the blog post list doesn't show the ... which is indicative the second paragraph added on the web editor doesn't seem to be there
• the post is still opened in Aztec the second time you want to edit it, even though the Post has been converted to Gutenberg on the web (Gutenberg should open in such case).

What I tried

I tested alpha-177 and couldn't reproduce even by following the same actions as shown in the video (didn't test on Android 9 but a Pixel 2 with Android 8.1 though). Tried on a self-hosted site with a slightly earlier version of Gutenberg as well, and a wordpress.com site, and it always opens the mobile Gutenberg editor for me the second time (after converting the post to blocks on the web), with the updated content in it.

Hypothesis followed

CASE A
I also tried following the hypothesis path of a Post with a local Id in the Posts list that is now changed by the time it's opened in the Editor (because of an hypothetical FLuxC Posts Fetch action finishing in the background due to the pull to refresh action triggered by the user), but that sounds quite far fetched: if the ID would refer to a missing Post then the Post can't be found and that would be it, but partially having the Title and status updated and not the Content sounds impossible in this case.

CASE B
I then thought it could be a content processing glitch that made the second Gutenberg paragraph not visible on Aztec.
But it turns out: in order for Aztec to be shown (as in the video), in alpha-177 we should have NOT detected any Gutenberg blocks in the Posts's content (as per the link to code above).
For that to happen, the Post content would have simply had not been updated.
Hence the only way this situation could occur is that the Title has effectively been updated, but the content wasn't.
In the web, you can see this is not the case.
So narrowing down, could have it been the case FluxC updated the Title but not the content?
How? Looked a bit into it and I could see FluxC handles updating the attributes of a Post atomically so, if we had some attributes and these were updated (such as the Published status and the title) then the content should have been effectively updated as well (which I think it did).
This can be seen in FluxC's code here, even the Status is set on the PostModel after the content has been set, so if we got the new Title and Status correctly we should have had the content as well - this effectively means that the most solid hypothesis right now is the data we got came from the server that way.

Conclusion I'm reaching to so far

This only leads me to think it may have been a glitch in the API: the information we have on our side came across like that from the server in any case.

To try to isolate it even more and make sure it was just a transitory problem, could you try again @designsimply and update here with your findings? As per your comment above it seemed it was consistently reproduceable so, we should still be able to find the same behavior with alpha-177 (you can download an approximate APK from 12.7 here or I can prepare an alpha-177 apk for you as well, just ping me). I'd be surprised to find it is still happening but if it does, then I'll be glad to have a way to reproduce and follow up from there.

The broader problem of syncing

Also to add to this in any case, I agree with the mentions and discussions above that the most prominent problem here is in effect the lack of a unified / consistent resolution strategy to handle versioning conflict that parts from the API, as discussed in p4a5px-2pK-p2 and mentioned in #10187 (comment) I'm also leaned to think a proper project would need to be scoped in order to tackle the root cause properly.

[designsimply]

I re-tested with wpandroid-12.7-universal.apk from here and found that I couldn't reproduce the problem where only part of my post was saved but the potential content loss we are still concerned about (and that is likely happening for users based on user reports we've received) is when you re-open and publish a post using the app that was edited and published on the web without refreshing the post list in the app first then it's easy to overwrite a published post with a draft.

• Test 1: 3m10s
• Test 2: 2m4s
• Test 3: 1m49s

^{Tested with WPAndroid 12.7 (apk from the GitHub releases section) on Pixel 3 Android 9.}

cc @shiki (and sorry for missing your ping before!)

[mzorz]

Thanks for testing again @designsimply !

I was re-reading the issue here to make sure to follow up on it correctly, here are my thoughts:

found that I couldn't reproduce the problem where only part of my post was saved

I think the way I understood this particular issue's description was the central part being this specifically:

Result: if a draft made with the app is edited and published on the web, the edits made using the web are not synced in the drafts post list and only the changes to the post title are synced after refreshing the published post list view and opening the post again. Changes made to the body of the post are lost. (3m40s)

I think, given the research done here and it wasn't reproduceable anymore is enough explanation (at least in regards to how WPAndroid works), we can close the issue.

The other problem (as in, the "broader problem of syncing") I think is better described as you did here:

we are still concerned about (and that is likely happening for users based on user reports we've received) is when you re-open and publish a post using the app that was edited and published on the web without refreshing the post list in the app first then it's easy to overwrite a published post with a draft.

What do you think about closing this one and opening a new one for this only that represents the situation as per the title in p4a5px-2pK-p2 Published Page reverted to Draft (that if a specific issue doesn't exist already ofc)?