fix(presence): prevent stale polling responses from overwriting newer websocket updates (#415)

[itssagarK]

What does this PR do?

This PR fixes a race condition in the presence synchronization system where delayed HTTP polling responses could overwrite newer real-time WebSocket updates.

Under certain network conditions, users could briefly appear offline or inactive even after a recent WebSocket presence update had already been received.

Changes Made

Timestamp-Based Presence Tracking

• Added a lastUpdated field to the LiveSession interface.
• Presence updates now record when they were received on the client.

Smart Polling Merge Logic

• Polling requests now track their request start time.
• When polling responses arrive, the client compares incoming data against the latest local presence state.
• Older polling data is ignored if a newer WebSocket update already exists.

Conflict Resolution

• Prevents stale HTTP responses from overwriting fresh real-time presence updates.
• Ensures the newest presence information always wins.

Offline Protection

• Preserves recently updated local sessions that may not yet be reflected in the server response.
• Prevents active developers from temporarily disappearing due to polling latency.

Why this matters

Before this fix

• A developer could start coding and immediately appear active via WebSocket.
• A delayed polling response could arrive afterward.
• The stale polling data could overwrite the newer state.
• Presence indicators could flicker or incorrectly show users as offline.

After this fix

• Real-time presence remains accurate.
• Stale polling responses are safely ignored.
• Presence synchronization becomes more reliable and deterministic.
• Users see the most recent activity state at all times.

Testing

Verified:

• WebSocket updates remain visible when delayed polling responses arrive.
• Polling continues to synchronize presence correctly.
• Active users are not incorrectly marked offline.
• No regressions in existing presence functionality.

Related Issue

Fixes #415

Checklist

• npm run lint passes
• Tested locally
• No secrets or .env values committed
• I acknowledge that an automated AI Reviewer will perform a preliminary review of this PR.
• ⭐ I have starred this repository! (We prioritize PRs and assignments for stargazers)

[vercel]

@itssagarK is attempting to deploy a commit to the ixotic27-8245's projects Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

✅ Security Scan: Clean

No suspicious patterns detected. The official Copilot bot will provide detailed AI feedback shortly.

⭐ If you enjoyed contributing, please consider starring the repository!

[itssagarK]

Hi @Ixotic27,

This PR fixes the presence synchronization race condition reported in #415.

The solution introduces timestamp-based conflict resolution so that delayed polling responses cannot overwrite newer WebSocket updates. This preserves accurate real-time presence while keeping the existing polling fallback mechanism intact.

Thank you for reviewing.

[github-actions]

🚨 Hey @itssagarK, the CI Pipeline is failing on this PR and it has been marked as status:blocked.

🔍 What failed:

• Production Build failed at step(s): Build

📋 Error Details (first 2):

• .github:2: Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/checkout@v4, actions/setup-node@v4. For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
• .github:49: Process completed with exit code 1.

Please fix the issues before this can be reviewed. Here's how:

1. Run checks locally before pushing:

npm run lint           # Run ESLint
npm run build          # Verify production build passes

2. Auto-fix common issues:

npm run lint -- --fix  # Auto-fix lint errors where possible

3. Check the full failure log here:
👉 View CI Run

Once you push a fix and the CI passes, the status:blocked label will be removed automatically. 💪