Editor: multiple posts being uploaded as duplicates on Jetpack sites #14221
Comments
|
I labeled this high priority because, based on our priority matrix, severity is critical due to unexpected publishing and impact is medium because we've only noted 2-4 user reports so far. Noting that if more user reports come in then we will raise priority to critical. (internal reference: paaHJt-UE-p2) |
|
Because it has been a few weeks since this issue was raised and there have been no new reports from users here on this issue and no replies from users on the support requests noted so far, I'm lowering priority to medium with an ask to please ping me right away if this comes up again. I think it sounds like a terrible problem and would like to help resolve the issue or direct users to where they can get help if it's not something we can control from the app side! For any future reports, it would help to know:
|
|
Another report of this happening:
Reported in 3333432-zen
They initially had the Sample API time-out error in the debugger as the other sites reported have had, but after disabling plugins this is showing 200 response. App logs for this user's initial report from 2020-09-20 with tokens/site names removed |
|
An update from 3333432-zen: User disabled their 4 plugins and the result:
They activated UpdraftPlus and the result was:
They then deactivate UpdraftPlus and activate Bluehost (along with Jetpack), the result was:
They will continue with disabling Bluehost and activating WooCommerce. They'll report the result after that. |
|
The user from 3333432-zen just confirmed there was no issue today when they published with WooCommerce active. @designsimply I just wanted to make sure this was on your radar since we've got some good new updates here. |
|
Thanks for the extra ping @rezzap! It sounds like this issue is happening to Bluehost+Jetpack users only and it would be good to keep posting any new cases at all that we can find and also, if possible, if we can get app logs from right after the problem happens that may also help us. We can also try testing from a Bluehost test site when timing allows. |
|
I've been looking into this issue and I want to share what I'm seeing from my pov: Incident reviewI started by reviewing the reports we've received. There seems to be a total of five individuals reporting, one uses the iOS app the others the Android app. Android
iOS
The only factor common to each case is Jetpack was installed, and that they were seeing duplicate posts on their sites. AnalysisWe have the most information from "Yel" an "Mirror". Both report seeing errors in the app when publishing, and that duplicates appear without them interacting with the error message. Causal theoryThere are a few touch points we can look at for the cause of the duplication:
Are we overlooking anything? I think we can rule out a glitch in the app code, or in the wpcom/Jetpack code being individually responsible for the issue. My rationale is that if either of these were the case, we should see orders of magnitude more reports than the five we have. I also think we can rule out hardware glitches since shouldn't see so many similar reports and that doesn't account for our iOS user reproducing dups from the desktop. The case of "Yel"Recall that the screen shots shared by "Yel" showed duplicate posts in both the Published and Drafts lists. A couple of scenarios occur to me that might explain this from the app's perspective. First, suppose the app attempts to publish a local draft with no post ID. The post is published successfully, but the server returns an error (or mangled response the app would interpret as an error). There is now a draft (still with no post ID), and a remote post. In this scenario more duplicates can be created as publishing is retried. We've encountered cases where malformed responses (particularly with XML-RPC) created problems with the apps in the past so I think this is within the realm of possibilities. Second, suppose that the app's background process that handles auto uploading is interrupted after the request to publish a draft is sent, and before the response is received. Perhaps the interruption is due to lost connectivity, or maybe the app is terminated. This will be interpreted as a failure status and the publish attempt would be retried later. This seems rather unlikely in this case simply because how consistently the issue is affecting "Yel". iOS Code auditI spent some time auditing the iOS publishing code, particularly the upload coordinators, and performing offline/online publishing tests. I experienced a few issues due to the quality of the network I was testing with, and a known issue with Gutenberg taking forever to load when developing, but happily the app successfully published as expected with no dups in my test cases. There is a lot of code at play, but from my read and tests there was nothing obvious that would contribute to the issue our user was seeing. And, again, if there were we'd expect to hear more reports, on iOS in particular. A final thought about the desktop reportI'm curious about the report the duplication also happens on the desktop by our iOS user. If this is the case then the issue is 100% outside of the app, and potentially unrelated to Jetpack if publishing was not occurring via calypso. Take awaysIn the case of "Yel" I'm inclined to chalk this up to something particular to our user's site and outside our ability to control, or that needs to be addressed in the iOS app. In the case of our Android users, I haven't done a deep dive into the Android code (and there are others who would do a better job) so I won't say there couldn't be an in-app cause. But, at least in the case of "Mirror" the issue is potentially due to a combination of plugins (pending further reports). |
|
I investigated this issue as an effort to identify which open issues are still valid. I believe this to be a valid issue in the latest WPiOS app. I was able to identify steps to somewhat consistently reproduce this issue, or at least a similar issue that I believe is likely related to what has been reported so far. I did not look into the code in an attempt to address the issue, but hopefully this information proves helpful whenever we invest further time. Network connectivity has been mentioned a few times in the various threads, and that was also my initial hunch when considering this issue as well. From my testing below, quickly modifying the network connection status does result in multiple posts being published. ReproductionReproduction screen recordingwp-ios-duplicate-posts.mp4Environment
Steps to Reproduce
N.b. I have no idea whether "quickly" in the list has an impact, but figure it does since the issue is likely related to actions taken during disrupted network connectivity. Expected ResultA single copy of the recently created post is published. Actual ResultTwo copies of the recently created post are published. Additional NotesI was unable to reproduce this on WordPress.com simple or Atomic sites. So, maybe there is something about the networks requests required for the Bluehost environment, or potentially the plugins enabled for the site I tested.
I then disabled (and ultimately re-enabled) all of the WooCommerce plugins and was unable to reproduce the issue again. My thought is that it has nothing to do with the plugins I toggled, but mere chance in regards to my network connectivity during testing. I also noticed one other oddity. After reproducing the issue of multiple posts published, I navigated to the Post Settings for each of the duplicative post within the mobile app. Surprisingly, the slug for each post was the same (e.g. |
The faulty mechanism for auto-publishing posts was removed from the app in 24.9. |
We've received at least 3 reports so far similar to the following and we need help troubleshooting and tracking these cases to look for trends or to find the reason why the app keeps going with publishing retries after at least one successful publish goes through.
(internal references: 3010797-zen p4a5px-2yY-p2 h/t @rezzap)
Sample snippet from a random editor session from the app logs from this user:
Then later in the same set of logs…
The
auto_upload_post_invokedlooks suspicious to me in this context, but the logs don't say which post that was invoked for so I can't tell for sure if it's the same one from the previous log snippet. You can find the full set of app logs for that session in the sidebar in 3010797-zen.The text was updated successfully, but these errors were encountered: