[Bug]: Presence polling responses can overwrite newer WebSocket presence update

[itssagarK]

Bug Description

The application uses WebSocket events for real-time presence updates while also running periodic HTTP polling as a fallback mechanism.

Under certain network conditions, an older polling response can arrive after a newer WebSocket event has already updated the client state. When this occurs, stale polling data overwrites the newer presence information and causes the UI to display incorrect user activity.

This can result in active developers appearing offline or inactive even though a more recent WebSocket update has already been received.

Steps to Reproduce

1. Open the city view with presence indicators enabled.
2. Start a coding session so a WebSocket presence update is received.
3. Simulate network latency on the polling endpoint.
4. Allow an older polling request to resolve after the WebSocket update.
5. Observe that the presence state reverts to outdated information.

Expected Behavior

Newer presence updates should always take precedence over older data.

Polling responses should not overwrite more recent WebSocket state if the client has already received a newer update.

Screenshots / Screen Recordings

The issue appears to occur because polling and WebSocket updates share the same state without a mechanism to determine which update is newer.

A timestamp or version-based validation strategy could help prevent stale polling responses from overwriting recent WebSocket updates.

I would be happy to work on this issue under GSSoC 2026 if it is confirmed and assigned.

Browser

Chrome

Acknowledgements

• I have searched existing issues to make sure this is not a duplicate.
• I have read the CONTRIBUTING.md guidelines.
• ⭐ I have starred this repository! (We prioritize issue assignments for stargazers)

[github-actions]

Hey @itssagarK, thank you for raising this issue! 🙌

This has been flagged for the project admin to review. We will discuss it internally and get back to you with next steps.

In the meantime, please make sure you've provided:

• 📝 A clear description of the problem or feature request
• 🖼️ Screenshots or logs if applicable
• 📂 Relevant file paths or code references

Sit tight — we'll update you soon! 💙

[itssagarK]

Hi @Ixotic27,

I investigated the presence synchronization flow and found a potential race condition between polling responses and WebSocket updates.

I have already analyzed the root cause and would be happy to work on a fix under GSSoC 2026 if the issue is confirmed.

Please assign this issue to me.

Thank you.

[github-actions]

Hi @itssagarK, thank you for your interest! 🙌

However, this issue has not been approved for contribution yet. It must be reviewed by the maintainer and given the gssoc:approved label before you can be assigned. Please wait for approval!

[itssagarK]

Proposed Solution

Hi Mentors! I am an active GSSoC 2026 contributor. I analyzed the presence synchronization flow and found a potential race condition between WebSocket updates and fallback polling responses.

Root Cause Analysis

The application receives real-time presence updates through WebSockets while also periodically fetching presence data through HTTP polling.

Since network requests can resolve out of order, an older polling response may arrive after a newer WebSocket event has already updated the UI. When this happens, stale polling data overwrites the latest presence state, causing incorrect user activity indicators and UI flickering.

Proposed Solution

I will introduce a lightweight timestamp/version validation mechanism for presence updates.

Implementation Plan:

// Track latest applied update
const latestPresenceVersion = useRef(0);

// WebSocket update
if (incoming.version > latestPresenceVersion.current) {
  latestPresenceVersion.current = incoming.version;
  setPresenceState(incoming.data);
}

// Polling update
if (response.version > latestPresenceVersion.current) {
  latestPresenceVersion.current = response.version;
  setPresenceState(response.data);
}

This ensures:

• Newer updates always win.
• Stale polling responses cannot overwrite recent WebSocket updates.
• Existing polling fallback behavior remains unchanged.
• Presence indicators stay accurate during varying network conditions.

My workspace is already set up and I would be happy to work on this issue under GSSoC 2026. Please assign it to me if approved.

Thank you!

[github-actions]

Hi @itssagarK, thank you for your interest! 🙌

However, this issue has not been approved for contribution yet. It must be reviewed by the maintainer and given the gssoc:approved label before you can be assigned. Please wait for approval!

[github-actions]

✅ Admin Approved!

Hi @itssagarK, this issue has been reviewed and approved by the project maintainers. Since you raised this issue, you have been automatically assigned to it! 🚀

⏰ Deadline: You have 48 hours from this exact moment to submit a Pull Request.

📝 Important - PR Submission Rules:

1. Branch Name: Please name your branch starting with the issue number (e.g., 415-feature-name).
2. PR Description: Make sure your Pull Request description includes Fixes #415.

🔒 This conversation will now be locked. Please use your Pull Request for any further discussion about this issue.