Avoid Onboarding screen when WK thinks DB is not schema-compliant

[philippotto]

In the past, we had at least two occurrences where a WK production system showed the onboarding system, because it considered the DB to be empty. No data was lost, but nevertheless the screen is scary.

We should do the following two things:

• [ ] avoid that the onboarding screen appears in such scenarios
• [x] double-check that the onboarding screen cannot delete data when somebody uses it to create a new organization

Some notes on when this happened:

• we updated a wk instance and used a docker tag that wasn't pushed. kubernetes didn't find the image and kept the old one deployed.
• the db migration was executed (--> the DB schema was too new for the wk version)
• the onboarding screen appeared instead of the dashboard

[fm3]

Some first insights: The onboarding screen was not shown because of the schema compliance check, but because the organization list query failed (since the columns of the organization table were changed in that particular migration). This means that

• this case is more rare that you may have feared
• the onboarding screen couldn’t even have created a new organization, since the insert statement would have suffered the same problems. Generally, the onboarding screen calls createOrganizationWithAdmin, which is the same as the standard register form. So it can indeed not destroy existing data.

Do you know in what circumstances the other of the two occurrences happened?

[fm3]

I managed to reproduce the issue and for me the /api/organizationsIsEmpty request correctly replies with 400 when the database access for the organizations table fails. Looks like the frontend catches this 400, and then displays the onboarding screen.

So I’d exchange the backend for the frontend label for this issue. Let me know if you think the backend should behave differently.