fix runtime error

[neithium]

This pull request makes a small but important update to the simulated real-time data changes in the Dashboard component. The change ensures that the code safely handles cases where systemInfo may be null, preventing potential runtime errors.

• Improved data simulation logic in Dashboard.js to guard against null systemInfo by providing default values for cpu_usage and memory_usage during updates.

What happened (root cause)

• The Dashboard component initializes data.systemInfo as null:
  • const [data, setData] = useState({ ..., systemInfo: null })
• There are two independent effects:
  1. An async fetch effect that calls the API and sets data.systemInfo when the response arrives.
  2. A setInterval effect that runs immediately after mount and updates prev.systemInfo.cpu_usage every 5s.
• Because the fetch is asynchronous, the interval can run before the API response arrives (race condition). When that happens, prev.systemInfo is null and the interval's updater attempts to read prev.systemInfo.cpu_usage, causing the uncaught runtime error:
  • "can't access property 'cpu_usage', prev.systemInfo is null"

Why the error appeared only after a few minutes

• The interval runs repeatedly; if at some point an API call failed, returned null, or data.systemInfo was overwritten to null, the next interval tick would crash.
• React shows these errors when the updater code dereferences a null object; repeated execution makes the crash visible after mount or after transient network conditions.

What I changed already

• I patched the interval updater to guard against null systemInfo before reading properties and to use safe defaults:
  • It now does:
    • const prevSys = prev?.systemInfo || { cpu_usage: 25, memory_usage: 50 }
    • compute next values from prevSys.cpu_usage and prevSys.memory_usage
  • This prevents the crash even if the API hasn't returned or returned null.

Recommended additional fixes (pick any or all)

1. Initialize systemInfo as a safe default when fetch completes

   • In your fetch effect, when you call setData with systemInfo, coerce it to a sensible default:

   // inside fetchDashboardData after getting systemInfo from API
   setData({
     monitoringStatus,
     trafficStats,
     alertSummary,
     vncSessions,
     systemInfo: systemInfo || { cpu_usage: 25, memory_usage: 50 }
   });

   • This ensures other UI logic always has a real object to read.

2. Only start the interval after data is available

   • Change the interval useEffect to depend on data.systemInfo and only create the interval if systemInfo is non-null:

   useEffect(() => {
     if (!data.systemInfo) return;
     const interval = setInterval(...); // same updater but can rely on data.systemInfo
     return () => clearInterval(interval);
   }, [data.systemInfo]);

   • This avoids running the updater until there's a baseline value.

3. Defensive rendering across the component

   • Use optional chaining when reading systemInfo elsewhere, e.g. data.systemInfo?.cpu_usage ?? '-'.
   • Avoid assuming nested properties always exist.

4. Add retry/timeout handling for the API

   • If the API intermittently returns null, fix the backend or add retries and sensible fallbacks on the frontend.

Suggested next action (I can implement it)

• I can add the initialization change (option 1) to Dashboard.js so the UI uses defaults immediately when the fetch returns null. This is a small, safe change and will further harden the dashboard.
• Do you want me to apply option 1 (initialize systemInfo with defaults on fetch) now? If yes, I will patch the file and restart/rebuild the frontend container and then you can verify the error no longer appears.

How to verify locally (commands)

• Restart frontend and watch browser console:

# restart with docker-compose
docker compose restart exfil-frontend

# view logs to ensure frontend served
docker compose logs exfil-frontend --tail 50 -f

• Or, if developing locally inside frontend:

# from repository root
cd containers/frontend
npm start
# open browser at http://localhost:3000 and watch console

Summary

• Root cause: race between async fetch and interval updater; prev.systemInfo was null when updater ran.
• Fix applied: interval updater now guards against null and uses defaults.
• Optional improvement: initialize systemInfo with defaults on fetch or start interval only after fetch; I can apply either if you want—tell me which and I'll implement it.
  This pull request improves the reliability of the simulated real-time updates in the Dashboard page by guarding against potential null values in systemInfo. This ensures that the dashboard does not crash if systemInfo is missing or undefined.

Robustness improvements to real-time data simulation:

• In Dashboard.js, the setData function within the interval now checks for a null or undefined systemInfo and provides default values for cpu_usage and memory_usage, preventing runtime errors during simulation.

[neithium]

@VeerajRatrikar @LikhithSP THE PR #30 is not required, made some minor fixes to make it work instead..