Rescue gitaly errors across all API endpoints

What does this MR do and why?

Adds global error handling for Gitaly service unavailability across all API endpoints to return proper 503 Service Unavailable responses instead of 500 Internal Server Errors and 502 Bad Gateway. Issue: #570220

Problem

When Gitaly or Praefect services are unavailable or unreachable, API endpoints return:

• 500 Internal Server Error - Incorrectly categorizes infrastructure issues as application bugs
• 502 Bad Gateway - Generic error without context

This happens because Gitaly connection failures can manifest as:

1. Direct GRPC errors (GRPC::Unavailable, GRPC::DeadlineExceeded) - When the gRPC client can't connect or times out
2. Wrapped Git errors (Gitlab::Git::CommandError with GRPC::Unavailable as cause) - When Git operations fail due to Gitaly being down

Solution

Added two global rescue handlers in lib/api/api.rb:

1. rescue_from GRPC::Unavailable, GRPC::DeadlineExceeded - Catches direct gRPC errors (connection failures and timeouts)
2. rescue_from Gitlab::Git::CommandError - Catches wrapped Gitaly errors (only when caused by GRPC::Unavailable or GRPC::DeadlineExceeded)

Both handlers now return:

• HTTP 503 Service Unavailable status
• Descriptive error message: "Gitaly service temporarily unavailable"
• Exception tracked in error monitoring

Benefits

1. Consistent error responses - Same 503 response regardless of error path
2. Global coverage - Applies to ALL API endpoints, not just pipelines
3. Proper HTTP semantics - 503 indicates temporary service unavailability
4. Better debugging - Clear error message identifies the root cause
5. Reduced noise - Infrastructure issues no longer trigger application error alerts
6. Complete coverage - Handles both connection failures AND timeouts

Example

Before: $ curl -i /api/v4/projects/123/pipelines/456/jobs HTTP/1.1 500 Internal Server Error {"message":"500 Internal Server Error"}

After: $ curl -i /api/v4/projects/123/pipelines/456/jobs HTTP/1.1 503 Service Unavailable {"message":"Gitaly service temporarily unavailable"}

How to test

1. Stop Praefect/Gitaly: gdk stop praefect
2. Make any API request that requires Git data: curl -H "PRIVATE-TOKEN: "
   http://localhost:3000/api/v4/projects//repository/commits
3. Verify response is 503 with message "Gitaly service temporarily unavailable"
4. Restart Praefect: gdk start praefect
5. Verify same request now returns 200 OK

testing screenshots

BEFORE

AFTER

Technical Details

Why two handlers?

Gitaly errors can reach the API layer via two different paths:

1. Direct path: Gitaly Client → GRPC::Unavailable → API
2. Wrapped path: Git Operation → GRPC::Unavailable → WrapsGitalyErrors → Gitlab::Git::CommandError → API

The second handler checks e.cause.is_a?(GRPC::Unavailable) to ensure we only return 503 for Gitaly connection issues, not other CommandError types (invalid refs, permissions, etc.).

---

MR acceptance checklist

• Code changes

  • Added global error handlers in lib/api/api.rb
  • Handlers return 503 for Gitaly unavailability and timeouts
  • Both GRPC::Unavailable and GRPC::DeadlineExceeded handled
  • Errors are tracked in error monitoring

• Tests

  • Added test for GRPC::Unavailable
  • Added test for GRPC::DeadlineExceeded
  • All 86 tests in spec/requests/api/api_spec.rb passing
  • No regressions

• Documentation (if needed)

  • N/A - Internal error handling change, no user-facing docs needed

• Manual testing

  • Tested with Praefect down → Returns 503
  • Tested with Praefect up → Returns 200

  ---

  This MR changes the global API error handling to properly categorize Gitaly service unavailability as temporary infrastructure issues (503) rather than application errors (500).