fix: Empty screen for signed user

[HornedHeck]

BUG
When I try to open stoat-for-web for self-hosted instance for already signed in user, I see empty screen.

REASON
Client.ts tries to connect to WebSocket by the url specified in the configuration. However it does not await for results of configuration sync in constructor. It leads to the fact that configuration.ws is empty and is not value WebSocket url.

STEPS:

1. Sign in to stoat
2. Close the tab
3. Open stoat in new tab (not in private window)

EXPECTED
Signed-in experience is visible and accessible.

[Taureon]

ACK 👍

[Dadadah]

I am unable to replicate the issue. Please open a git issue with more details.

It seems to me that you may have your self-hosted environment misconfigured.

[HornedHeck]

I am unable to replicate the issue. Please open a git issue with more details.

It seems to me that you may have your self-hosted environment misconfigured.

1. As with any issue related to mt\async execution, it is hard to achieve 100% reliable reproduction strategy.
2. I followed stoat-provided instruction for configuration of self-hosted instance (server, web-client).
3. I observe somewhat similar problems mentioned in another PR: fix: fetch server configuration on client initialization for invite_only servers #152

Also the current code seems somewhat strange for me. For guest users (or bots) client awaits for configuration fetch in login and loginBot before attempting to connect. While for signed-in users this step is skipped and web-client simply calls connect directly, without any intermediate steps.

[Dadadah]

1. As with any issue related to mt\async execution, it is hard to achieve 100% reliable reproduction strategy.
2. I followed stoat-provided instruction for configuration of self-hosted instance (server, web-client).
3. I observe somewhat similar problems mentioned in another PR: fix: fetch server configuration on client initialization for invite_only servers #152

That PR didn't actually do anything, the invite only issue was already fixed, and I've closed it.

Also the current code seems somewhat strange for me. For guest users (or bots) client awaits for configuration fetch in login and loginBot before attempting to connect. While for signed-in users this step is skipped and web-client simply calls connect directly, without any intermediate steps.

The configuration is fetched during client initialization, so fetchConfiguration doesn't need to be called anywhere anymore. I just didn't remove the older calls. You are right that it's possible that the configuration is not fetched by time connect() is called, however, this problem is addressed in the for-web repo by having the websocket set by a VITE environment variable. If your for-web client is failing to connect to the right websocket before configuration is fetched, this is a configuration issue with your for-web client.

The self-hosted repo generates a .env.web file that has all of the vite variables automatically filled out. If you're trying to connect a developing verison of the for-web repo, you must copy the variables in .env.web to the .env file in the for-web repo.

Edit: If there's anything to change about this, it would be to make connect() throw an error if configured() is false.

[HornedHeck]

1. Configuration Fetch

The configuration is fetched during client initialization
If you are talking about #fetchConfiguration in Clients' constructor, then I can not agree with you. #fetchConfiguration is asynchronous method and we can not establish any happened-before relationships with other parts of the code. In other words it is incorrect to say "fetched during initialization", instead it should be something like "started fetching during initialization".

2. Web-client configuration correctness

this is a configuration issue with your for-web client.

Correct me if I am wrong, but the following snippet (from web client):

  DEFAULT_WS_URL:
    (import.meta.env.DEV ? import.meta.env.VITE_DEV_WS_URL : undefined) ??
    (import.meta.env.VITE_WS_URL as string) ??
    "wss://stoat.chat/events",

should return default stoat web socket url ("wss://stoat.chat/events"). But for me it was "", despite env var was set to non-empty value.

3. Summary

TBH, I do not want to argue, whether my config is correct or not (it may be incorrect). There are still configuration options that are part of code, but are not controlled by env variables. All of them can have different values in server-side configuration compared to client side (now and in future). Right now the code contains a race condition in form of what would happen first: #fetchConfiguration would succeed or property read would happen. Even without fixing my issues with ws url, it is definitely worth it to remove such a problem from library, including security reasons.