[Web App Marketplace]Handle API Responses Separately Instead of Generic Error

[sacheeramesh]

Description

In the Web App Marketplace, multiple API responses are currently handled as generic errors, which leads to poor user experience and lack of clarity. Each scenario should be handled separately with specific UI messages and behaviors. Users must clearly understand the issue — whether it’s due to missing data, access restrictions, or an internal system error.

Expected Behavior

Each case should have distinct handling:

1. When user has no apps (apps/[user])

   • Show a clear message: “No authorized apps.”
   • This indicates the user does not have access to any applications.

2. When the API fails (e.g., 500 error)

   • Display an Internal Server Error page with an appropriate message.
   • Example: “Something went wrong while loading apps. Please try again later.”

3. When user has no favorite apps

   • Show a clear message: “You haven’t favorited any apps yet.”

4. When the favorite apps API fails

   • Display an Internal Server Error page similar to the above case.

Actual Behavior

• All these scenarios are currently handled as generic errors, which do not help users understand what went wrong.

Steps to Reproduce

1. Log in to the Web App Marketplace.
2. Access different sections (Apps, Favorites) with missing data or failing APIs.
3. Observe that the system shows generic or unclear error messages for all cases.

Notes

• Each API response should be validated and handled separately in both frontend and backend.
• Use consistent UI components for displaying empty states and error messages.
• Ensure internal server errors are logged for debugging.
• Apply this handling pattern across all APIs in the Web App Marketplace.

Labels

bug, ui, error-handling, backend, web-app-marketplace, usability

[dinethde]

Already fixed the issue in PR #18