Start: Blank page caused by IndexedDB state

ebinnion commented 2 years ago

Quick summary

I noticed that when I was logged in to my account and then went to /start that I got a blank page. Further, when I went to the sidebar in my sites and clicked to "Add new site" I got a similar blank page.

After debugging, it appears that the issue was something in the signup IndexedDB value. I was able to "fix" the state by deleting the signup key and then trigger the issue again by adding the same value into that key.

See Slack for the state of that key. I can also share a snippet that I used to set the IndexedDB state.

p1655499865537459-slack-C02FMH4G8

Steps to reproduce

This one was a bit weird to reproduce. The steps that I took are:

Go to WordPress.com
Set the state for the signup key. You'll likely need to make adjustments for your own sites and/or user ID
Go to /start/domains
Ensure that you see a blank page
If you don't see a blank page immediately, set the value again. Production seemed relatively easy to reproduce on. Development was pretty difficult to reproduce on.

In the days before this, the only thing new that I had done was migrate a self-hosted Jetpack site on Pressable to Atomic (eric.blog) and then I also migrated the eric.blog domain to be associated with the new cache site on WPCOM.

What you expected to happen

No blank page.

What actually happened

Blank page.

Context

No response

Simple, Atomic or both?

No response

Theme-specific issue?

No response

Browser, operating system and other notes

No response

Reproducibility

No response

Severity

No response

Available workarounds?

No response

Workaround details

No response

griffbrad commented 2 years ago

@Automattic/team-calypso-frameworks Let’s take a look at this one. I don’t think it’s related to the core state persistence support in Calypso. It’s likely something specific about the way that persisted state is being handled in these flows, but we may be able to provide some insight into how these types of errors can be avoided going forward.

tyxla commented 2 years ago

Haven't looked yet, but at a first glance, this looks like a case where we're not leveraging persistence properly. Many of our reducers rely on persisted state but declare a schema for the data, and if the local data doesn't comply, it's thrown away. Looks like declaring and leveraging a schema for the signup state tree should do the job.

tyxla commented 2 years ago

Took another quick look, and made a few observations - sharing here, in case they can be useful for whoever ends up further investigating:

I've double-checked and tested Calypso's persistence mechanism by altering the local data to not conform to the schema. Persistence behaves as expected, and invalid data is thrown away. Valid data is properly persisted, as expected.
The signup state tree doesn't have persistence itself. However, its subtrees do have schemas defined, and they're being referenced with withSchemaValidation to leverage the schema validation.

I'm assuming that what's going on here is either:

The schema of a data piece is unexpected and doesn't match what a component actually passes for storage or consumes from the storage. I'd bet on this to be the higher chance.
Our persistence mechanism not working correctly with a certain type of data, meaning we either fail to serialize a certain type of data, or we unserialize to an unexpected format. I'd doubt this is the one, but anything is possible.

In any case, I'd recommend after getting to reproduce it, looking out for any errors that could hint as to where it's failing. If there are none, we're likely swallowing the error. In that case, the step it fails on could be a good hint on where to start. To debug this, I'd suggest debugging at where we actually load and store persisted state - respectively:

https://github.com/Automattic/wp-calypso/blob/d179ad30ca0f8f80720a993cafb4bc0fa6628b6f/client/state/persisted-state.js#L15

and

https://github.com/Automattic/wp-calypso/blob/d179ad30ca0f8f80720a993cafb4bc0fa6628b6f/client/state/persisted-state.js#L34

and comparing whether the data before serialization matches the data after loading the persisted state. I'm assuming they won't match, and the place where they don't match should hint at where the culprit could be.

@griffbrad @ebinnion I think it makes sense for folks who are more familiar with the signup flows to further debug this (perhaps @Automattic/martech-decepticons ?) but I'm also happy to provide further support to anyone who needs it - let me know.

jamiepalatnik commented 2 years ago

📌 HOUSEKEEPING

Labels ✅
Priority ✅
Replicable on Core - N/A

📌 SCRUBBING

Did not test since I don't know how to set the IndexedDB state and it looks like this is already being investigated. Noting that I added the priority high since it sounds like there is no workaround for any users affected by this issue.

📌 ACTIONS

Marked as Triaged for Quality Squad review

cometgrrl commented 2 years ago

@Automattic/martech-decepticons Y'all were flagged in Slack as possibly being the right team to look into this one. Is that correct?

cometgrrl commented 2 years ago

Lowered priority to normal since we don't have clear repro steps and we only have one report.

gmovr commented 2 years ago

May or may not be helpful, but x-posting just in case :)

I also had this today, and it was related to p1658245766758849-slack-C096PD42U. I thought I fixed it for myself by clearing Memcache, and clearing indexed DB.

But after making a new site, the next time I went to /start it would do the same thing.

In my case I looked in Kibana for my user, and I it was errors from my sandbox (more context in the Slack above).

lsl commented 1 month ago

Recent report here p1722212069911599-slack-C02FMH4G8 - at least in terms of similar outcome.

I don't know whether the original report in this PR is still relevant but we could start by re-trying the snippet from Eric in the slack thread here: p1655499865537459-slack-C02FMH4G8

Aside from that, if there is some kind of unexpected and silent error happening that leads to the wsod being shown lets try to both log the error's and show the user/HE's something meaningful that we can trace better.

Done here means:

[ ] Any edge cases we can reproduce are resolved
[ ] Any general case that leads to a wsod during onboarding is logged and an appropriate error screen is shown to the user

davemart-in commented 2 weeks ago

Moving to "needs more info"

Automattic / wp-calypso