Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • reliability reliability
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1,815
    • Issues 1,815
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Insights
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.com
  • GitLab Infrastructure Team
  • reliabilityreliability
  • Issues
  • #4249
Closed
Open
Created May 18, 2018 by Stan Hu@stanhuMaintainer

500 Errors in /api/v4/projects/<project_id>/repository/branches/master

https://log.gitlab.net/goto/d0e571f3c5370e337c5af610f774e399 shows a steady stream of 500 errors:

image

The quick Kibana summary shows that of 500 entries, 30% of them belong to:

/api/v4/projects/4655045/repository/branches/master

That endpoint works fine for me as an admin user. I can't seem to get it to return a 500 error.

The reason I'm interested is that I've been seeing unusually high call times from the handle_api_exception method in there and in the commonly called /api/v4/internal/allowed endpoint:

image

This method logs an error to Sentry, but I can't seem to find relevant Sentry errors. I'm wondering if Sentry queuing is delaying the return of this method.

Assignee
Assign to
Time tracking