Profile and Card pages show "Not Found" for network/server errors

[IshitaMittal29]

🐞 Describe the Bug

When the backend is unavailable, the Profile and Card pages show "Profile not found" and "Card not found" even though the requested profile/card may still exist.

For example, if the backend server is not running and I visit /u/test or /devcard/test, the browser console shows ERR_CONNECTION_REFUSED, but the UI still displays a "not found" message.

The issue is not that the request fails when the backend is down. The issue is that all API failures are treated as "not found" responses, making it impossible to distinguish between an actual 404 and a network/server error.

Steps to reproduce:

1. Run the web app with the backend unavailable.
2. Visit /u/test or /devcard/test.
3. Observe the UI and browser console.

Expected behavior:
A network/server error should show a more appropriate message (e.g. unable to load profile/card) and reserve "not found" only for genuine 404 responses.

Actual behavior:
All failures are displayed as "Profile not found" or "Card not found".

Environment

• OS: Windows 11
• Browser: Brave

[github-actions]

Hi @IshitaMittal29,

Thanks for opening this issue.

Please reply with one of the following areas so the issue can be routed to the appropriate team member:

- /backend
- /web
- /mobile
- /devops

Once an area is selected, the corresponding label will be added automatically.

[github-actions]

👋 Thanks for opening your first issue, @IshitaMittal29!

We appreciate your contribution and are excited to have you here. Please make sure to follow the contribution guidelines and provide as much detail as possible.

To stay updated, ask questions, and connect with maintainers and contributors, please join our Discord community:
https://discord.gg/QueQN83wn

Looking forward to collaborating with you!

[IshitaMittal29]

/web

[github-actions]

The issue has been classified as web.

@ShantKhatri, please review and triage this issue when available.

The web label has been applied and the issue has been routed accordingly.

[virakshi07]

/assign

Hello Maintainers 👋

I would like to work on this bug under GSSoC'26.

Understanding of the Issue

Currently, the Profile (/u/:username) and DevCard (/devcard/:username) pages treat all API request failures as "not found" scenarios.

This results in misleading behavior because:

• Genuine 404 responses (resource does not exist) and
• Network/server failures (backend offline, connection refused, timeout, 500 errors)

are handled identically.

For example, when the backend server is unavailable, the frontend receives a network error (ERR_CONNECTION_REFUSED), yet the UI still displays:

• "Profile not found"
• "Card not found"

This makes debugging difficult and provides incorrect feedback to users, who may assume the profile/card does not exist when the real issue is a temporary server or connectivity problem.

The goal of this fix is to implement proper error classification so that users receive accurate and meaningful feedback based on the actual failure type.

---

Detailed Implementation Plan

Phase 1: Error Handling Flow Analysis

• Review the Profile page data fetching logic.
• Review the DevCard page data fetching logic.
• Identify API service/helper functions responsible for requests.
• Analyze current error handling implementation.
• Determine where all failures are being mapped to the "not found" state.

---

Phase 2: Error Classification Strategy

Separate failures into distinct categories:

Resource Not Found (404)

• Profile genuinely does not exist.

• DevCard genuinely does not exist.

• Show existing:

  • "Profile not found"
  • "Card not found"

Network Errors

Examples:

• Backend offline
• Connection refused
• DNS failure
• Request timeout

Display a more appropriate message such as:

Unable to load profile. Please check your connection or try again later.

or

Unable to load card. The server may be temporarily unavailable.

Server Errors (5xx)

Examples:

• Internal Server Error
• Bad Gateway
• Service Unavailable

Display a dedicated server error state rather than a "not found" message.

---

Phase 3: Improve API Response Handling

• Inspect response status codes before determining UI state.

• Handle:

  • 404 responses
  • 500+ responses
  • Network exceptions
  • Request cancellations
  • Timeout failures

Ensure each error path maps to the correct user-facing state.

---

Phase 4: Create Dedicated Error States

Introduce clear UI states for:

Loading State

• Data currently being fetched.

Success State

• Profile/Card renders normally.

Not Found State

• Only displayed for verified 404 responses.

Network Error State

• Display connectivity-related messaging.

Server Error State

• Display backend/service availability messaging.

This improves both user experience and debugging clarity.

---

Phase 5: UI/UX Improvements

• Provide clearer and more actionable messages.

• Maintain consistency with the application's design language.

• Avoid exposing technical stack traces or raw error messages.

• Optionally include:

  • Retry button
  • Refresh action
  • Return navigation

if appropriate within existing UI patterns.

---

Phase 6: Shared Error Handling Refactor

If both Profile and DevCard pages share similar logic:

• Extract reusable error handling utilities.
• Standardize API error interpretation.
• Reduce duplicate code.
• Improve maintainability for future pages.

---

Phase 7: Edge Case Testing

Test scenarios including:

404 Responses

• Non-existent profile.
• Non-existent dev card.

Network Failures

• Backend server stopped.
• Connection refused.
• Offline browser mode.
• Network interruption.

Server Failures

• 500 Internal Server Error.
• Service unavailable.
• Unexpected API responses.

Normal Cases

• Existing profile.
• Existing dev card.

---

Phase 8: Validation

Verify:

✅ "Not Found" appears only for actual 404 responses

✅ Network failures show appropriate connectivity messages

✅ Server errors display dedicated error states

✅ Existing profile/card rendering remains unchanged

✅ No regressions introduced to current routing behavior

✅ Consistent behavior across both Profile and DevCard pages

---

Expected Outcome

✅ Accurate distinction between 404 and network/server failures

✅ Improved user experience

✅ Better debugging visibility

✅ More reliable error handling

✅ Consistent behavior across Profile and DevCard pages

✅ Cleaner and more maintainable frontend logic

I have experience working with frontend API integration, error boundary handling, HTTP status management, and user-friendly error state design, and I would be happy to contribute this fix.

Looking forward to your approval. Thank you! 🚀

[Harxhit]

@IshitaMittal29 I have assigned this issue to you.

[Harxhit]

@virakshi07 There are opened good first issues that you can work on.