Bug: Messages not appearing on first run after 'make clean setup dev'

**Migrated from GitHub issue icub3d/decentcom#93** **Original Author:** @icub3d **Original Date:** 2026-04-18T20:29:19Z --- ## Overview When running `make clean setup dev`, the client successfully connects and shows the server/channels, but the message list remains empty. Restarting the client fixes the issue, suggesting a race condition during the initial environment bootstrap. ## Background The `make clean setup dev` command: 1. Clears databases and WebView `localStorage`. 2. Seeds fresh test data (Alice as active account, `OPEN` as current server with messages). 3. Starts all servers and the client simultaneously via `overmind`. ## Requirements - [x] Client should reliably load messages on the first run after a fresh setup. - [x] Race conditions between identity loading, app store rehydration, and auto-connection should be eliminated. - [x] Auto-connection should have a basic retry backoff to handle servers starting up. ## Potential Causes & Design Changes ### 1. App Store Rehydration Race In `App.tsx`, `initAppStoreForAccount` is called in a `useEffect`. This function explicitly sets `currentServerId` to `null` before calling `rehydrate()`. ```typescript useAppStore.setState({ currentServerId: null, servers: {}, theme: defaultTheme(), }); await useAppStore.persist.rehydrate(); ``` If the auto-connect effect triggers before or during this, it may use a stale or `null` server ID, or trigger multiple connection attempts. ### 2. Connection Status Flapping In `useServerStore.ts`, `connect()` fetches channels/roles, then calls `gateway.reconnect()`, then `loadMoreMessages()`. The WebSocket `onopen` handler sets `status: 'connected'` as soon as the socket opens. This might happen BEFORE `loadMoreMessages` finishes, causing the UI to render an empty list (as `messages` is still `{}`). ### 3. Server Startup Latency `cargo watch` takes a few seconds to start the server. The client retries immediately on failure, which might lead to a state where it thinks it's connected but failed to fetch initial data. ## Task List - [x] Fix `initAppStoreForAccount` to avoid unnecessary `null` state if the account hasn't actually changed. - [x] Ensure `useServerStore.connect` clears previous messages/channels to avoid stale data. - [x] Add a `loadingMessages` state or similar to `useServerStore` to distinguish between "fetching" and "no messages". - [x] Add retry backoff to the auto-connect logic in `App.tsx`. ## Test List - [x] Run `make clean setup dev` and verify messages appear in `#general` on the first client load. - [x] Verify that switching accounts still correctly rehydrates and connects. - [x] Verify that the "Loading..." state is shown while messages are being fetched on initial connection.

icub3d commented

2026-04-26 16:46:22 +00:00

Owner

Migrated from GitHub issue icub3d/decentcom#93
Original Author: @icub3d
Original Date: 2026-04-18T20:29:19Z

Overview

When running make clean setup dev, the client successfully connects and shows the server/channels, but the message list remains empty. Restarting the client fixes the issue, suggesting a race condition during the initial environment bootstrap.

Background

The make clean setup dev command:

Clears databases and WebView localStorage.
Seeds fresh test data (Alice as active account, OPEN as current server with messages).
Starts all servers and the client simultaneously via overmind.

Requirements

Client should reliably load messages on the first run after a fresh setup.
Race conditions between identity loading, app store rehydration, and auto-connection should be eliminated.
Auto-connection should have a basic retry backoff to handle servers starting up.

Potential Causes & Design Changes

1. App Store Rehydration Race

In App.tsx, initAppStoreForAccount is called in a useEffect. This function explicitly sets currentServerId to null before calling rehydrate().

  useAppStore.setState({
    currentServerId: null,
    servers: {},
    theme: defaultTheme(),
  });
  await useAppStore.persist.rehydrate();

If the auto-connect effect triggers before or during this, it may use a stale or null server ID, or trigger multiple connection attempts.

2. Connection Status Flapping

In useServerStore.ts, connect() fetches channels/roles, then calls gateway.reconnect(), then loadMoreMessages().
The WebSocket onopen handler sets status: 'connected' as soon as the socket opens. This might happen BEFORE loadMoreMessages finishes, causing the UI to render an empty list (as messages is still {}).

3. Server Startup Latency

cargo watch takes a few seconds to start the server. The client retries immediately on failure, which might lead to a state where it thinks it's connected but failed to fetch initial data.

Task List

Fix initAppStoreForAccount to avoid unnecessary null state if the account hasn't actually changed.
Ensure useServerStore.connect clears previous messages/channels to avoid stale data.
Add a loadingMessages state or similar to useServerStore to distinguish between "fetching" and "no messages".
Add retry backoff to the auto-connect logic in App.tsx.

Test List

Run make clean setup dev and verify messages appear in #general on the first client load.
Verify that switching accounts still correctly rehydrates and connects.
Verify that the "Loading..." state is shown while messages are being fetched on initial connection.

icub3d

closed this issue
added the
area:ux

type:bug

area:api

status:complete
labels

Rows
Columns

Bug: Messages not appearing on first run after 'make clean setup dev' #66