Editor / Post List: Issues syncing posts

[aerych]

trafficstars

As @rachelmcr mentioned in p4a5px-1Sr-p2

We regularly get users who report problems with the app not syncing their content, even if there aren’t any apparent issues with their server or internet connection. I’ve been doing some testing in both iOS and Android and there’s a particular scenario I’m concerned about:

Leaving the Blog Posts screen open

• A user creates or edits a post in the app.
• The user closes the editor but stays on the Blog Posts screen.
• The user goes to a web browser (on the same or a different device) and makes further edits to the post.
• The user returns to the app (still on the Blog Posts screen) and opens the post to make more edits.

In this scenario, nothing triggers the Blog Posts screen to sync with the remote changes and the user will open an old version of the draft. This causes users to overwrite remote changes (especially likely in the Android app, since even if they realize the problem and exit the editor we autosave the local version) and there’s no clear way to restore an older revision of the post.

If the user published the post in step 3, and then updated the non-synced post in the app, this will also revert the post to a draft.

Is there any way we can either trigger a sync in this scenario or offer some kind of hint/prompt that the user might want to manually sync the screen?

Not noticing that the posts are syncing

If I pull down to manually sync my content, both apps show a spinner that indicates the posts are syncing. However, there’s no clear indicator in the app itself when I open the Blog Posts screen to show me that the posts are syncing. (If I look closely, I’ll see a spinner in the iOS status bar, but that’s easy to overlook.) That can lead to another scenario:

• A user creates or edits a post in the app.
• The user leaves the editor and Blog Posts screen to go to another part of the app.
• The user goes to a web browser (on the same or a different device) and makes further edits to the post.
• The user returns to the app.
• The user opens the Blog Posts screen and the app starts syncing their content.
• Before the sync finishes, the user opens the post in the editor to make more edits.

In this scenario (which I can reproduce even on a fast internet connection), the user once again opens an old version of the draft and can overwrite the newer remote version of the draft. A clear (possibly blocking) indicator in this scenario could stop the user from opening the post before it has synced with the remote changes.

[aerych]

Also refs: p4a5px-1WR-p2

[SiobhyB]

This came up in 273697-h. The user would like a way to revert local changes to their posts, so that they don't override changes they made on their desktop.

[SiobhyB]

@aerych: We still regularly see reports of this issue, both in ZD and in app reviews. A recent example is in 1506610-z.

I wanted to check whether making a note of these reports here is worthwhile or not? I don't want to add to the noise, but also don't want to assume that you're aware that we get fairly frequent reports around this issue.

[aerych]

I'm not sure we were aware (this had certainly fallen off my radar) so reports are definitely welcome.

We're adding support for post revisions to the app, and this should help with the problem of overwriting content but the race conditions described in the issue are tricky to resolve.

It would be helpful to know if the reports coming in match one of the scenarios mentioned int he issue description or if there is something different happening.

[rachelmcr]

I came across another case of "Not noticing that the posts are syncing" in 2397161-zen (h/t @sarahfg and @charliescheer for raising/discussing the issue):

• The user started a post on their iPad and saved it as a draft.
• They finished the post and published it on their iPhone. The post was published on their site and an email was sent to their subscribers.
• The next day, they checked their iPad and saw the post was still a draft there. (At this point the app should have been syncing with the remote changes.)
• They opened the draft to inspect it and try to understand why it was still in draft status and only partially complete.
• They updated the post to see if the rest of the changes they had made on their iPhone would appear.

Two issues stand out here:

1. There was no indication that the posts were syncing.
2. The "Update" action for the post was misinterpreted — that action updates the remote post with the local changes, but the user understood is as updated the local post with the remote changes.

[thehenrybyrd]

I believe this is what happened in 2451829-zen as well, so another report.

[mchowning]

In this scenario, nothing triggers the Blog Posts screen to sync with the remote changes and the user will open an old version of the draft. This causes users to overwrite remote changes...

Retested and confirmed that this is still an issue.

[designsimply]

This came up in a support request in Jun 2021 and was investigated at that time. As part of that investigation, advice was given to try disabling markdown syntax on the WordPress.com Writing Settings page to see if that would help but we never heard back from the user after that.

Original problem description from the user:

The website and the app on my iPhone aren’t synching up correctly. I posted from my laptop and my phone app has my latest post still in the drafts folder.

Latest advice we sent them:

Please disable the "Write posts or pages in plain text Markdown syntax." option on this page: https://wordpress.com/settings/writing/example.com

It was also noted in the investigation that these synchronization issues are complex and deserve more time than can be given in a single maintenance rotation and that we should consider addressing it at a project level. I'm adding this note so I can close out that internal investigation with an ask to continue tracking the problem in this issue, and I also noted that we can also take the option to send it back to maintenance to see if we can chip away at it if we are unable to dedicate project time for it in the near term.

^{(internal references: p4a5px-2Kk-p2, 4283109-zd-woothemes, p1626348192002500-slack-C029FFD8E, p1626347397480900-slack-C011BKNU1V5)}

[IoanaAMuresan]

Another related issue here, perhaps: 24196384-HC Customer makes edits in the iPad app -> not reflected in the live site, nor in the editor when logged in using a browser. Can't test / replicate (don't have an iPad). Suggested a hard reset of the app - waiting to hear if that made any difference (Follow up ticket here: 4559981-Zen)

[joashrajin]

Similar report in #5504971-zen

In this case, the user created a draft on an iPad. When they then went to their iPhone and viewed the drafts, it hadn’t updated.

When they pushed the update button on the iPhone app, the post disappeared and defaulted back to the point where they had left off. They were finally able to restore it via the “history” area on their iPad though.

[crazytonyli]

Please note, the app (the current version is v23.4) also retries updating a post if it failed to update. The retry mechanism can happen automatically in the background when user launches the app.

That means, it's possible the following scenario may happen:

1. User makes changes to a post (or a page) in the app. They can't save the change due to slow network connection, outage, or whatever.
2. User stops using the app, switches to their computer, and edits the post successfully.
3. A few weeks/months later (user may continue to make changes to the post during this time), user opens the app. By this point, they don't even remember the above happened (why would they).
4. However, the app's automatic retry mechanism kicks in and updates the post with an old content that the user made in step 1, which overwrites all edits that were made to the post during the weeks or months since last time they open the app.

[sentry[bot]]

Sentry issue: WORDPRESS-IOS-45XF

[guarani]

I labeled this High Priority because the above Sentry issue is a log event that says that in the 23.6 beta, so far one user (at the time of writing) had their post overwritten (e.g. the app is about to overwrite a post revision created on another device), which is bad. Using the priority matrix, pbArwn-1gZ-p2, it's Severity Critical (due to data loss) + Impact Low (due to one report in the beta) = High Priority.

[sentry[bot]]

Sentry issue: JETPACK-IOS-15ZB

[sentry[bot]]

Sentry issue: WORDPRESS-IOS-4616

[derekblank]

@crazytonyli This issue appears to be escalating in Sentry reports since the release of 23.6.0.1:

Error Domain=PostEditor.OverwritePost Code=1 "(null)"

The stack trace points to PostService.checkLatestRevision. Would you be able to take a look (and perhaps become the DRI on the Sentry issue if they seem related)?

• https://github.com/wordpress-mobile/WordPress-iOS/pull/21892
• https://github.com/wordpress-mobile/WordPressKit-iOS/pull/637

cc @mokagio

[crazytonyli]

Hi @derekblank , thanks for linking the Sentry stats. To be clear, the sentry events trend is not an indicator that this issue is escalating. The sentry issue (or the new checkLatestRevision function) doesn't have any negative impact on the app's quality.

The app has been having this "syncing issue" for a very long time, but there is no way (other than customer feedback) to detect those issues.

As you can see in the comment history, there are many different scenarios that may lead customers to believe there is a "syncing issue" in the app. One of the scenarios is https://github.com/wordpress-mobile/WordPress-iOS/issues/8111#issuecomment-380783723

The user would like a way to revert local changes to their posts, so that they don't override changes they made on their desktop.

The new "PostEditor.OverwritePost" error events are merely a way to detect and surface the underlying issue where app's post changes override desktop changes.

However, I sense maybe Sentry is the wrong tool for collecting this data? Maybe it has gotten in the way of the issue triaging process?

[derekblank]

The new "PostEditor.OverwritePost" error events are merely a way to detect and surface the underlying issue where app's post changes override desktop changes.

Gotcha, thank you clarifying. During this triaging period we have been experiencing unexpected spikes in other areas, so this context is helpful to cross-check that these events aren't related.

However, I sense maybe Sentry is the wrong tool for collecting this data? Maybe it has gotten in the way of the issue triaging process?

No, I agree that Sentry would be valuable to collect these error reports (rather than relying on user reports), and also agree that the triaging process can focus too much on quantitative reporting metrics. To help future triagers encountering this linked issue, we can note that the increase in Sentry events is intended.

[filipanoscampos]

Reported in 7369486-zd-a8c

[sentry[bot]]

Sentry issue: JETPACK-IOS-161G

[dvdchr]

This issue is mentioned in these app reviews:

• https://appfigures.com/reviews/334311506925LJTT3IxMkMEWjyveVxyTsTw?lang=en
• https://appfigures.com/reviews/334311506925LV4vfGLJmQn2SoCx0mYUAHQ?lang=en

[kean]

This is no longer applicable: the sync issues have been addressed in the scope of the "Offline Mode (Sync Issues)" project (pilot in 24.8; release in 24.9).