feat: enhance error handling in git-push and repo services

[dcoric]

Summary

This PR fixes both:

• Fixes Poor error messaging in the admin UI when the user is not logged in #1392
• Fixes Improve UI error handling and API error codes #1188

Improve error handling and test coverage for UI services

This PR refactors error handling across the UI service layer and adds comprehensive test coverage. Error handling is now consistent, type-safe, and properly tested.

What's changed

Error handling improvements:

• Added src/ui/services/errors.ts with reusable error utilities (getServiceError, errorResult, successResult)
• Refactored git-push.ts and repo.ts services to use the new error handling utilities
• Updated UI views (PushDetails.tsx, RepoDetails.tsx, etc.) to properly handle and display error states
• All service functions now return consistent ServiceResult<T> objects with success/failure states

Test coverage (14 → 79 tests):

• test/ui/errors.test.ts - comprehensive tests for error utility functions (18 tests)
• test/ui/user.test.ts - tests for user service functions (13 tests)
• test/ui/git-push.test.ts - expanded coverage for all git-push functions (13 tests)
• test/ui/repo.test.ts - expanded coverage for all repo functions (21 tests)

Tests cover success paths, HTTP errors (401/403/404/409/500), network failures, and edge cases.

Benefits

• Consistent error handling - all services use the same pattern
• Better UX - proper error messages shown to users
• Type safety - TypeScript ensures correct error handling
• Test coverage - prevents regressions and documents expected behavior

Addition to this PR - Error Boundary

New file src/ui/components/ErrorBoundary/ErrorBoundary.tsx

ErrorBoundary class component with getDerivedStateFromError (render capture) + componentDidCatch (logging)

Wraps all route content in and catches any render error from any view without taking down the sidebar/navbar

It has 2 modes - dev and production. In dev mode it has option to display stacktrace of the error, in production mode only offers option to reload:

DEV:

PROD:

[netlify]

✅ Deploy Preview for endearing-brigadeiros-63f9d0 ready!

Name	Link
🔨 Latest commit	2c2b093
🔍 Latest deploy log	https://app.netlify.com/projects/endearing-brigadeiros-63f9d0/deploys/699e99abbfbf6200081625cb
😎 Deploy Preview	https://deploy-preview-1406.git-proxy.preview.finos.org
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.78%. Comparing base (6713757) to head (2c2b093).
⚠️ Report is 14 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1406   +/-   ##
=======================================
  Coverage   81.78%   81.78%           
=======================================
  Files          67       67           
  Lines        4766     4766           
  Branches      827      827           
=======================================
  Hits         3898     3898           
  Misses        852      852           
  Partials       16       16           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jescalada]

Looks good so far, thanks for all the extra UI tests!

What I had in mind when I first made the error handling refactor ticket was some sort of wrapper component (context?) that would catch any errors happening in API calls and forward the error to a toast. I'm aware this would require a lot of extra refactoring, so I might have to clarify the details and we can deal with it in a separate PR.

Note that I haven't tested behavior yet - will complete the review later this week 👍🏼

[kriswest]

Very happy to see this being done (particularly redirects to login on 401s and use of the API's error messages) and would love it to go into 2.0 (as the current situation is awful). I only have a couple of minor comments to add to Juan's.

[fabiovincenzi]

Looks good to me, and it covers #1402 , thanks @dcoric!

[dcoric]

Looks good so far, thanks for all the extra UI tests!

What I had in mind when I first made the error handling refactor ticket was some sort of wrapper component (context?) that would catch any errors happening in API calls and forward the error to a toast. I'm aware this would require a lot of extra refactoring, so I might have to clarify the details and we can deal with it in a separate PR.

Note that I haven't tested behavior yet - will complete the review later this week 👍🏼

I have explored universal API error messaging. It is doable with shared axios instance with a response interceptor + react-toastify (or similar) that would auto-surface API errors as toasts without per-service error handling. I would tackle this in a separate PR (and do a cleanup as well)

Addition to this PR:
I have added an ErrorBoundary component to catch and display UI render crashes gracefully. In development it shows the error message and stack trace; in production it shows a user-friendly message with a retry option.

[jescalada]

I noticed a few errors that are either caught elsewhere or don't make it into the ErrorBoundary:

Non-existent user

Non-existent push

This might happen if accessing a link to a push that later got removed from the database somehow:

For /dashboard/repo/<repo-id> this is working correctly:

---

Another thing I noticed is that we still get the errors in the console. Not sure if we should keep these for debugging (as they sometimes contain additional context vs. the stack trace) or not.

[jescalada]

LGTM after fixing those! 👍🏼

[dcoric]

@jescalada Addressed both issues:

• Non-existent user/push routes: UserProfile and PushDetails now throw on error instead of rendering <Danger> inline, so the ErrorBoundary catches and displays them properly.
• Console errors: console.error in ErrorBoundary.componentDidCatch and auth.ts is now gated behind a dev-mode check, no noise in production.

[jescalada]

LGTM!