fix(011): improve WebSocket sync and EKS configuration

- Replace optimistic updates with delayed refetch pattern to prevent race conditions
- Add NEXT_PUBLIC_WEBSOCKET_URL build arg to frontend Dockerfile for runtime configuration
- Upgrade EKS cluster version from 1.28 to 1.29 for latest features
- Remove hardcoded availability zones, let eksctl auto-select for better flexibility

Why: Optimistic updates were causing UI inconsistencies when WebSocket events arrived
before database commits completed. The 500ms delay ensures data consistency.
EKS 1.29 provides improved security and performance features.

Author: DanielHashmi

frontend/Dockerfile

@@ -24,6 +24,10 @@ WORKDIR /app
 COPY --from=deps /app/node_modules ./node_modules
 COPY . .
 
+# Build arguments for Next.js public env vars
+ARG NEXT_PUBLIC_WEBSOCKET_URL
+ENV NEXT_PUBLIC_WEBSOCKET_URL=$NEXT_PUBLIC_WEBSOCKET_URL
+
 # Build the application
 ENV NEXT_TELEMETRY_DISABLED=1
 ENV NODE_ENV=production

frontend/app/dashboard/DashboardClient.tsx

@@ -102,59 +102,23 @@ export default function DashboardClient({ session: initialSession }: DashboardCl
   const { updateName, updateImage } = useProfileUpdate();
   const { isSyncing, pendingCount, lastError } = useSyncQueue();
 
-  // Phase V: WebSocket for real-time task updates with optimistic updates
+  // Phase V: WebSocket for real-time task updates
   const { connectionState, isConnected } = useWebSocket({
     onTaskCreated: useCallback((taskData: Record<string, unknown>) => {
-      // Optimistically add the new task to local state
-      revalidateTasks(
-        (currentTasks) => {
-          if (!currentTasks) return currentTasks;
-          const newTask = taskData as Task;
-          // Check if task already exists (avoid duplicates)
-          if (currentTasks.some(t => t.id === newTask.id)) {
-            return currentTasks;
-          }
-          return [newTask, ...currentTasks];
-        },
-        { revalidate: false } // Don't refetch from server
-      );
+      // Refetch tasks after 500ms delay to allow DB commit
+      setTimeout(() => revalidateTasks(), 500);
     }, [revalidateTasks]),
     onTaskUpdated: useCallback((taskData: Record<string, unknown>) => {
-      // Optimistically update the task in local state
-      revalidateTasks(
-        (currentTasks) => {
-          if (!currentTasks) return currentTasks;
-          const updatedTask = taskData as Task;
-          return currentTasks.map(t =>
-            t.id === updatedTask.id ? updatedTask : t
-          );
-        },
-        { revalidate: false } // Don't refetch from server
-      );
+      // Refetch tasks after 500ms delay to allow DB commit
+      setTimeout(() => revalidateTasks(), 500);
     }, [revalidateTasks]),
     onTaskCompleted: useCallback((taskData: Record<string, unknown>) => {
-      // Optimistically update completion status in local state
-      revalidateTasks(
-        (currentTasks) => {
-          if (!currentTasks) return currentTasks;
-          const completedTask = taskData as Task;
-          return currentTasks.map(t =>
-            t.id === completedTask.id ? { ...t, completed: completedTask.completed } : t
-          );
-        },
-        { revalidate: false } // Don't refetch from server
-      );
+      // Refetch tasks after 500ms delay to allow DB commit
+      setTimeout(() => revalidateTasks(), 500);
     }, [revalidateTasks]),
     onTaskDeleted: useCallback((taskData: Record<string, unknown>) => {
-      // Optimistically remove the task from local state
-      revalidateTasks(
-        (currentTasks) => {
-          if (!currentTasks) return currentTasks;
-          const deletedTask = taskData as Task;
-          return currentTasks.filter(t => t.id !== deletedTask.id);
-        },
-        { revalidate: false } // Don't refetch from server
-      );
+      // Refetch tasks after 500ms delay to allow DB commit
+      setTimeout(() => revalidateTasks(), 500);
     }, [revalidateTasks]),
   });
 

k8s/aws/eks-cluster-config.yaml

@@ -1,5 +1,5 @@
 # EKS Cluster Configuration for LifeStepsAI
-# AWS EKS 1.28 with OIDC enabled for IRSA
+# AWS EKS 1.29 with OIDC enabled for IRSA
 # Region: us-east-1, Multi-AZ: us-east-1a, us-east-1b
 # Node type: 2x t3.medium (4 vCPU, 8GB RAM total)
 
@@ -9,7 +9,7 @@ kind: ClusterConfig
 metadata:
   name: lifestepsai-eks
   region: us-east-1
-  version: "1.28"
+  version: "1.29"
   tags:
     Environment: production
     Project: LifeStepsAI
@@ -38,10 +38,8 @@ nodeGroups:
     volumeSize: 20  # GB
     volumeType: gp3  # General Purpose SSD v3 (cost-effective)
 
-    # Multi-AZ deployment for availability
-    availabilityZones:
-      - us-east-1a
-      - us-east-1b
+    # Multi-AZ deployment for availability (let eksctl choose zones automatically)
+    # availabilityZones will be determined by eksctl based on available subnets
 
     # IAM policies for EKS worker nodes
     iam: