Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pages listing pages fails to render due to requesting unused data about each Post #45317

Open
getdave opened this issue Sep 1, 2020 · 14 comments

Comments

@getdave
Copy link
Contributor

getdave commented Sep 1, 2020

Before reading on please see p2EDhh-18T-p2.

Essentially on sites with very large Pages and lots of revisions/attachments the Pages page in the Calypso UI can fail due to a 500 error from the REST API. If it doesn't fail then it can take upwards of 10s to load the view.

Currently Calypso makes a blanket request to the endpoint for all data relating to each Page. However, most of the data isn't required for this particular view. Instead, we should explore requesting the specific subset of the data required to display a list of Pages (eg: ignore revisions, attachments...etc). Requesting a subset of data protects somewhat against the 500 error which may be due to memory usage.

See the p2 post for more details on how to filter the requests to only return particular fields for each Page.

Steps to reproduce

This is difficult to reproduce. You should see the p2 post for an example site that will cause the error to manifest itself.

What I expected

The Pages listing page to render a list of Pages quickly and consistently.

What happened instead

The Pages list page either:

  • Took +10s to load.
  • Failed to load due to a 500 error from the REST API

Browser / OS version

All

@mreishus
Copy link
Contributor

mreishus commented Sep 1, 2020

When I navigate to the posts page in calypso (example url: http://calypso.localhost:3000/posts/example.com), I see the API request fired off to //public-api.wordpress.com/rest/v1.1/sites/12345678/posts include &number=20 as a parameter, which caps the number of results returned to 20, even if there are more. When we were debugging earlier, the public-api urls we were testing did not include &number=20. Is there a way for a user to hit the /v1.1/sites/12345678/posts endpoint without including a &number=20 parameter?

@davemart-in
Copy link
Contributor

This seems like it's larger than a simple Janitorial issue. Sending this one back to the Ajax team to prioritize in their backlog.

@github-actions
Copy link

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

@davipontesblog
Copy link
Contributor

@tjcafferkey, is there to prioritize this in the next janitorial run? See p2EDhh-18T-p2#comment-6586 for more context. Thanks!

@davipontesblog davipontesblog added the Triaged To be used when issues have been triaged. label Apr 9, 2021
@tjcafferkey
Copy link
Contributor

@obenland I'm moving this to the Manage Backlog so there's more visibility on it, and to ensure it gets properly triaged. Also to make sure it's not overlooked/missed in our teams backlog as this is getting phased out.

@bobmatyas
Copy link

3983254-zen is another more recent example of this happening.

@davipontesblog davipontesblog added this to Needs triage in HE Triaging Board (new bugs) via automation May 25, 2021
@davipontesblog
Copy link
Contributor

Moving back to triaging board since it's been reopened.

@davipontesblog davipontesblog removed the Triaged To be used when issues have been triaged. label May 25, 2021
@kosiew kosiew added the Triaged To be used when issues have been triaged. label May 25, 2021
@kosiew kosiew moved this from Needs triage to Triaged in HE Triaging Board (new bugs) May 25, 2021
@kwight
Copy link
Contributor

kwight commented May 27, 2021

@obenland FYI fo visibility, @taggon for flow patrol consideration.

@kwight kwight moved this from Triaged to Prioritized in HE Triaging Board (new bugs) May 27, 2021
@retnonindya
Copy link

Hi team! I would like to ask your assistance on this user's issue:
3983254-zd-woothemes (refer to @bobmatyas' comment above.)

The user requested us to assist on trashing/deleting the problematic page. Problem is, we can't trash/delete it.

I tried using Calypso-display and WP Admin-display, both to no avail.

When in Calypso-display, there will be a quick "Trash is failed" notification; then the page disappeared, as if the Trash process is successful. However, if we refreshed the Pages page again, the page reappears under Published.

When in WP Admin-display, it will lead to blank page with Error 500 warning.

In this case, how do we delete the page from the website? Since this website is a simple site (no plugin installed and not on Business plan,) I don't have access to PHPMyAdmin to delete the page. Thank you in advance 🙇

@retnonindya
Copy link

So sorry for the direct ping here since I noticed no movement at all 🙇‍♂️

@kwight, @taggon, @obenland -- I'm so sorry for the ping. Can you check or share some steps on how to trash a page (per above comment) as it's not possible to do so from Calypso and WP Admin? I'd figure we need developer's sandbox access for this.

I tried:

  • Trashing the page using Calypso,
  • Trashing the page using WP Admin, and...
  • Trashing the page using REST API method

All of them to no avail.

Since this is a public repo, I'm not putting the user information here. Feel free to let me know if there are better places to do so. Thank you 🙏

@kwight
Copy link
Contributor

kwight commented Jun 8, 2021

@retnonindya I was able to force delete the problematic old home page – from what I can tell, it was a huge amount of content, which I guess was contributing to out-of-memory errors. It no longer shows up in WP Admin, and everything seems to be working well for that user.

@retnonindya
Copy link

@kwight THANK YOUUUUUUUUU! ✨ Thank you so much thank you thank you thank you!

@davipontesblog
Copy link
Contributor

Is this something that can be closed now? Seems to be an isolated event for now.

@kwight
Copy link
Contributor

kwight commented Jun 9, 2021

I only fixed an individual user's semi-related problem – the OP issue remains (requesting huge amounts of page data can cause failing UI renders).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Pri] Normal Triaged To be used when issues have been triaged. [Type] Bug [Type] Performance
Projects
Development

No branches or pull requests

10 participants