76 lines
3.2 KiB
Markdown
76 lines
3.2 KiB
Markdown
Here is a clear and concise explanation of the task for an AI agent to fix the described problem.
|
|
|
|
---
|
|
|
|
### **Objective: Fix Session State Synchronization for New Clients**
|
|
|
|
Your task is to correct a bug in the application's real-time collaboration feature. Currently, when a new client joins an existing session, they see the application's default state, not the session's current, modified state. This creates a state desynchronization issue.
|
|
|
|
### **Problem Analysis**
|
|
|
|
The client-side application is already architected to handle an initial state dump upon connection.
|
|
|
|
1. **`useWebSocket.ts`:** When a message with `type: 'welcome'` is received, the hook is designed to take the `message.payload.state` object and pass it to the application's main state management hook.
|
|
|
|
2. **`useDrumMachine.ts`:** This hook has a `useEffect` that listens for incoming messages. It contains a specific `case 'state':` that correctly processes a full state object, updating the grid, bassline, tempo, steps, and other parameters.
|
|
|
|
|
|
The problem is not on the client side. **The root cause is on the server-side WebSocket implementation.**
|
|
|
|
The server is likely doing one of the following incorrect things:
|
|
|
|
- It sends a `'welcome'` message that does **not** contain the complete, current state of the session.
|
|
|
|
- It sends a `'welcome'` message with an empty or default `state` object.
|
|
|
|
- There is a race condition where the server sends the `'welcome'` message _before_ it has finished retrieving the current session state from its data store.
|
|
|
|
|
|
### **Required Implementation**
|
|
|
|
You must modify the **server-side** WebSocket logic to ensure state is synchronized correctly.
|
|
|
|
1. **On a new WebSocket connection:** When a client connects and provides a `sessionId`, your server-side code must immediately perform the following steps.
|
|
|
|
2. **Retrieve the complete current state** for that `sessionId`. This state must include:
|
|
|
|
- The drum `grid`
|
|
|
|
- The `bassLine`
|
|
|
|
- The current `tempo`
|
|
|
|
- The number of `steps`
|
|
|
|
- The `mutes` array
|
|
|
|
- The `drumVolume`
|
|
|
|
- The `bassVolume`
|
|
|
|
3. **Construct a `'welcome'` message.** This message must contain the full state object you just retrieved. The JSON payload sent to the newly connected client must follow this exact structure:
|
|
|
|
JSON
|
|
|
|
```
|
|
{
|
|
"type": "welcome",
|
|
"payload": {
|
|
"clientId": "UNIQUE_CLIENT_ID_FOR_NEW_CLIENT",
|
|
"state": {
|
|
"grid": [/* current grid state */],
|
|
"bassLine": [/* current bassline state */],
|
|
"tempo": 135, // The current tempo
|
|
"steps": 32, // The current number of steps
|
|
"mutes": [false, true, ...], // The current mute states
|
|
"drumVolume": 0.8,
|
|
"bassVolume": 0.5
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
4. **Send this `'welcome'` message** to the newly connected client _immediately_ upon their connection. This must be the very first message they receive, ensuring the UI is rendered with the correct state from the start.
|
|
|
|
|
|
This change will ensure that any client joining an in-progress session will see the exact same state as all other participants, resolving the synchronization bug. |