Wordpress-ios: Posts: Load more stat being spammed.

[aerych]

We're seeing the tracks event wpios_post_list_load_more_triggered (and potentially the related Mixpanel stat) being spammed since version 6.9 landed in the app store.

I've looked through some of the tracks data and it looks like a handful of users might be getting caught in a refresh loop loading more content. It does not seem to be limited to a particular model as iPhone and iPad are both showing up in the reports.

A similar issue with the reader's infinite scroll stat being bumped was traced back to a date/timezone issue. Its unclear if something similar is occuring here.

NOTE: The stat has been short circuited server side due to its being spammed. When this issue is patched, and available in the app store we'll want to roll back the change on the server.

[aerych]

Dug into this a bit more.

I've been working from the assumption that the controller is caught in a refresh loop, loading more over and over, but I've been unable to produce this behavior.
I've tried a variety of scenarios that have included lots of posts, few posts, no posts, different filters, fresh install, existing install and self-hosted and wpcom blogs, and resuming the list via state restoration, but so far no joy.

However, I believe I've found at least part of the x factor and I think we can try a preventative patch based on it.

To trigger a load more event the following must be true:

• the table view must be about to display one if its final rows.
• the list must not currently be syncing
• the list filter's hasMore property must be true

Currently the list filter's hasMore property defaults to true and is updated after syncing -- unless no posts are synced. That's an interesting and relevant caveat. In most cases, when the post list is loaded it automatically performs a sync in the background and the property gets updated. However, only one automatic sync is performed within a five minute window.

Now the fun part:
If, after an automatic sync is performed the user backgrounds the app (thus triggering state restoration), and later resumes the app (restoring state) prior to the end of the five minute window, the hasMore flag remains set to true. In this particular situation, if the list has already cached the sum of its content (meaning there are no more posts to fetch), the load more event can be repeatedly triggered by either scrolling the list to the bottom, or in some cases rotating the app.

I suspect these circumstances are a part of what triggers the stat to spam. I think the missing piece of the puzzle is something that's causing the table view to initiate a refresh after the call to load more posts completes. Regardless, I'm fairly confident that defaulting the hasMore property to false will fix the issue. Let's give it a try.

[aerych]

Sadly, it appears this patch did not solve the issue.

[aerych]

In #6965 we've removed the spamming stat, but the underlying issue remains. @koke has done some additional sleuthing (which I'll leave for him to summarize) but the cause remains illusive, and is potentially driving up bandwidth usage for affected users.

[aerych]

Note to self: See if this one is still an issue.

• [ ] Add a new stat to bump to test.
• [ ] Run for a release.
• [ ] Remove the stat if not needed / issue is resolved

[designsimply]

Removed the [Pri] High label because this issue has been inactive for ~1 year and 10 months and may not be a problem any longer. Please do add back the label if the stat reveals the need for this issue to get more attention soon!

[aerych]

See old internal thread at p4qSXL-1RM-p2 for more context.

[aerych]

This one slipped through the cracks.

I've checked tracks and for the past 30 days, of ~24,029 events there are 18 incidence of the stat being bumped with a count of 100. This means that load more was called at least 100 times in a row during the lifetime of a single AbstractPostListViewController instance. The 18 occurrences affect 14 users.

The take away is the problem still exists but its exceedingly rare. I don't have other insights to share at this time but I'm curious to see if there are any factors in common (platform, OS version, device version, self-hosted vs wpcom, etc.) I've tried investigating further with the cohort tool but there seems to be a glitch that needs sorting.