5 consecutive un-renderable WPCOM_Liveblog_Entry items breaks Liveblog

[mattoperry]

The lazy-loader retrieves entry objects in batches of 5 (or the number dictated by liveblog_number_of_entries to a max of 100). Let's call this $number.

Some retrieved entries may have the property:

[replaces] => /**(int)**/

and the additional private property:

[type:WPCOM_Liveblog_Entry:private] => delete|update

which indicates they are not for display, but are meant to modify another referenced entry. If all $number retrieved entries have the replaces property, Liveblog may behave unpredictably if it can't render those entires. This is guaranteed to be the case for delete, and is sometimes the case for update Depending on the circumstances it may:

• render none of the retrieved entries (confusing because it appears that the load more action did not work)
• fail to load any more entries when "load more" is clicked again.
• misrender one or more of the update entries in a way that causes it to break entirely for further "load more" clicks. For example, it may fail to find the most recent timestamp in the DOM and begin loading entires from the beginning again, resulting in duplciation

This seems broken. It seems like the correct behavior should be to always return $number renderable items. These would be entry objects without the replaces property, or replace / update entries that will result in a valid entry.

[jasonagnew]

@mattoperry I remember this being broken in the older releases which used Backbone before the switch to React. Have you been testing with an older version 1.6 or lower? I believe this doesn't happen in 1.7 or 1.8. Thanks.

[no-sws]

@mattoperry I was not able to recreate this issue in 1.8 to confirm @jasonagnew's comment. The only rendering issue I could see was that sometimes a page would not "fill up" after a deletion occurred (e.g., page 1 has entries A-E, and page 2 has entries F and G; after deleting entry E, sometimes entry F would not automatically populate on page 1), but this may be unrelated (and is corrected after paging). Thanks!

[mattoperry]

@jasonagnew @no-sws yes for sure this is relative to 1.6, so it could easily be fixed now. I'd be interested to find out when this was fixed (1.7 maybe?) this is probably related to the answer in #478

[no-sws]

Hi @mattoperry, I think my comment on #478 might be helpful/relevant here. Let me know if I'm way off or if you need any more clarification. Thanks!

[no-sws]

@mattoperry when testing something else I came across an issue that kinda reminds me of this issue but might be different enough to warrant a new issue.

To reproduce:

1. Log in as editor
2. Create a fresh liveblog post
3. Go the post's (from step 2) front-end
4. Add 7 entries (or $per_page + 2 entries)

At this point, in both Mac Chrome and Firefox, I am not able to page through and the pagination text is "1 of 1". If I browser refresh the page, I am able to page through and the pagination text is "1 of 2" on the first page.

Let me know what you think or if this has already been reported. Thanks!

[GaryJones]

Seems to have already been fixed, so closing this out.