Onboarding detection
geigerzaehler opened this issue · comments
At the moment, the mechanism that detects whether to show the onboarding screen is implemented by blocking the startup of the upstream-proxy services including the HTTP endpoint. This creates the following problems.
- If a user does not have an identity yet, the UI shows a spinner for one second and only then shows the onboarding screen.
- If the proxy fails to set up its HTTP endpoint but does not crash we show the onboarding screen—even if an identity exists. This masks errors and makes them harder to debug.
- Similarly, if it takes longer than one second for the proxy to provide the HTTP endpoint, we will show the onboarding screen. Even if an identity is present and the HTTP endpoint is created later.
- When the app is run from a terminal and closed on the onboarding screen we see an error on the terminal indicating that upstream-proxy process was killed.
To address these problems, the GET /session endpoint of the API should provide information on whether the user is onboarded or not.
Fixing the implementation is a blocked by radicle-dev/radicle-cli#77 as well as the fact that upstream-proxy creates an uninitialized profile on startup. If radicle-dev/radicle-cli#77 is not addressed we can only work around this by having the upstream-proxy not create an uninitialized profile. Addressing the radicle-cli issue is preferred.
With radicle-dev/radicle-cli#77 fixed it should be possible to remove the startup delay now. Could you take a look at this @efstajas?
@geigerzaehler sure thing, I will take a look after patch statuses is done 👍
I've also sometimes run into a weird race condition, where the onboarding screen doesn't advance to the profile screen after an identity is created. Instead it hangs and an app refresh leads to the unlock screen. Don't have reliable repro steps yet.