fix: resolve 500 server crash on settings and github-accounts api routes (#597)

[anjalikumari45]

Summary

This PR resolves a cascading 500 Internal Server Error affecting the dashboard Settings page, which caused the UI to fail with a "Failed to load" message. It cleans up broken fallback code and introduces robust error boundaries to ensure the settings dashboard always renders smoothly.

Closes #597

---

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ♻️ Refactor / code cleanup (no functional change)

---

What Changed

• src/app/api/user/settings/route.ts: Refactored fetchUserSettings to remove redundant database schema fallback blocks that incorrectly passed database errors down the chain, causing the GET function to return a hard 500 error. Configured fallback to return a clean, schema-safe default data object instead.
• src/app/api/user/github-accounts/route.ts: Added defensive try-catch and empty database match boundaries. If the accounts connection table fails or is uninitialized, the route now gracefully outputs an empty array ({ accounts: [] }) to the client instead of throwing an unhandled runtime error.

---

How to Test

1. Navigate to the dashboard settings page routing path (/dashboard/settings).
2. Simulate a local deployment environment where newer database columns or the user_github_accounts table schemas have not been seeded or migrated yet.
3. Access the settings panel directly.

Expected result:
The Settings page UI should render completely without dropping a "Failed to load" banner error. The sub-components should read empty fallback parameters cleanly instead of hitting crashing server API tracks.

---

Screenshots / Recordings

Before	After
UI crashes completely with a broken "Failed to load" string banner.	Settings UI containers render smoothly with graceful empty/fallback input state boundaries.

---

Checklist

• Linked the related issue above
• Self-reviewed my own diff
• No unnecessary console.log, debug code, or commented-out blocks
• npm run lint passes locally
• No TypeScript errors (npm run type-check)

---

Accessibility (UI changes only)

Skip - API optimization backend handling logic fix only.

---

Additional Context

The fix streamlines the progressive database structure logic so that environment-level table anomalies don't prevent the active user from configuring general settings preferences.

[github-actions]

Thanks for your first PR on DevTrack! 🎉

A maintainer will review it within 48 hours. While you wait:

• Make sure CI is passing (type-check + lint)
• Double-check the PR description is filled out and the issue is linked
• Feel free to ask questions in Discussions if you need help

If you find DevTrack useful, a ⭐ star on the repo is always appreciated — it helps the project grow and attract more contributors!

[github-actions]

GSSoC Label Checklist 🏷️

@Umbrella-io — please apply the appropriate labels before merging:

Difficulty (pick one):

• level:beginner — 20 pts
• level:intermediate — 35 pts
• level:advanced — 55 pts
• level:critical — 80 pts

Quality (optional):

• quality:clean — ×1.2 multiplier
• quality:exceptional — ×1.5 multiplier

Validation (required to score):

• gssoc:approved — counts for points
• gssoc:invalid / gssoc:spam / gssoc:ai-slop — does not score

Type labels (type:*) are auto-detected from files and title. Review and adjust if needed.
Points formula: (difficulty × quality_multiplier) + type_bonus

[anjalikumari45]

Hi ,

I have submitted a PR to resolve the 500 Internal Server Error occurring on the settings and GitHub accounts API routes (related to issue #597).

I have refactored the fetch logic to include proper error boundaries and graceful fallbacks, ensuring the dashboard renders correctly even when database schema migrations are pending. I have also verified that the changes pass linting and type-checking.

Whenever you have a moment, I would appreciate your review on this fix. Thank you!"

Tips for your comment:
Tag the Owner: Ensure you use the @ symbol followed by their GitHub username so they receive a notification.

Be Patient: As noted by the github-actions bot, maintainers typically review PRs within 48 hours. Avoid "pinging" them multiple times unless significant time has passed.

Keep it focused: You have already provided a great summary in the PR description, so this comment just serves as a polite nudge to draw attention to your work.

Would you like me to help you draft a specific response if the owner asks for changes later?