Problem to solve
When trying to access the GitLab WebIDE, it loads but appears empty without any files. This prevents users from utilizing the WebIDE functionality.
Specifically:
- The WebIDE interface loads, but no project files are visible.
- This differs from the expected behavior where project files should be accessible and editable within the WebIDE.
Error message observed in the logs:
NoMethodError (undefined method `pre_receive_secret_detection_enabled' for nil:NilClass
project.security_setting.pre_receive_secret_detection_enabled
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^):
...
NoMethodError (undefined method `pre_receive_secret_detection_enabled' for nil:NilClass
/opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/grape-2.0.0/lib/grape/middleware/error.rb:39:in `block in call!'
/opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/grape-2.0.0/lib/grape/middleware/error.rb:38:in `catch'
/opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/grape-2.0.0/lib/grape/middleware/error.rb:38:in `call!'
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'
...
duplicate key value violates unique constraint "namespace_aggregation_schedules_pkey"
caught error of type NoMethodError in after callback inside Grape::Middleware::Formatter : undefined method `pre_receive_secret_detection_enabled' for nil:NilClass
caught error of type NoMethodError in after callback inside Grape::Middleware::Formatter : undefined method `pre_receive_secret_detection_enabled' for nil:NilClass
Additional log information:
- Error log:
{"severity":"ERROR","time":"2024-08-21T10:50:56.426Z","correlation_id":"01J5T8Z8XCP7CSC2NZFNCT3DRH","meta.caller_id":"GET /api/:version/projects/:id","meta.remote_ip":"10.230.15.1","meta.feature_category":"groups_and_projects","meta.user":"raffaele.vitiello","meta.user_id":2,"meta.project":"zz/xx/yy/xx/yy","meta.root_namespace":"xx","meta.client_id":"user/2","exception.class":"NoMethodError","exception.message":"undefined method `pre_receive_secret_detection_enabled' for nil:NilClass\n\n project.security_setting.pre_receive_secret_detection_enabled\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"}
- Nginx access log:
10.230.15.1 - - [21/Aug/2024:10:50:55 +0200] "GET /api/v4/projects/zz%2Fxx%2Fyy%2Fxx%2Fyy HTTP/2.0" 500 39 "https://[GITLAB_URL]/-/ide/project/zz/xx/yy/xx/yy/edit/sonartest/-/.gitlab-ci.yml" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36" -
Steps to reproduce
- Log into GitLab
- Navigate to a project (e.g., zz/xx/yy/xx/yy)
- Attempt to open the WebIDE (e.g., by accessing /-/ide/project/zz/xx/yy/xx/yy/edit/sonartest/-/.gitlab-ci.yml)
- Observe that the WebIDE loads but is empty
- Note that the API call to
https://[GITLAB_URL]/api/v4/projects/zz%2Fxx%2Fyy%2Fxx%2Fyy
returns:{"message":"500 Internal Server Error"}
Troubleshooting steps already taken:
- Checked and cleared GitLab cache using
gitlab-rake cache:clear
- Performed a full check using
gitlab-rake gitlab:check
- Checked db migrations using
gitlab-rake db:migrate:status
and re-rangitlab-rake db:migrate
- Attempted to reconfigure GitLab using
gitlab-ctl reconfigure
- Restarted GitLab services using
gitlab-ctl restart
- Checked GitLab logs for specific errors
- Verified LDAP settings
Configuration
Our GitLab instance uses LDAP for authentication and Omniauth. Elasticsearch is also enabled.
Proxy configuration:
- http_proxy: http://[PROXY_SERVER]:8080
- https_proxy: http://[PROXY_SERVER]:8080
- no_proxy: [INTERNAL_DOMAINS]
Versions
- Self-managed
- GitLab.com SaaS
Versions:
- GitLab: 17.3.0-ee
- Ruby Version: 3.1.5p253
- Redis Version: 7.0.15
- DB Version: PostgreSQL 14.11
Additional Information
- The issue appears to be related to project security settings or permissions.
- We’re using an Omnibus installation of GitLab.
- The problem seems to affect multiple users and projects.
- The error occurs when trying to access project information via the API.
- GraphQL requests to the API seem to complete successfully (status 200) but may not be returning the expected data.
- We are using the Premium Tier with GitLab Duo, which might be relevant to this issue.
Calling the same API with my PAT works fine when I include the repository tree endpoint, but fails when I use the same endpoint that the WebIDE is using. Here’s a demonstration:
- This call works and shows project content, files, and directories:
curl --header "PRIVATE-TOKEN: xxx-xxxxxxxxxxx-xx" "https://[GITLAB_URL]/api/v4/projects/zz%2Fxx%2Fyy%2Fxx%2Fyy/repository/tree?recursive=true&ref=sonartest" -I
HTTP/2 200
date: Wed, 21 Aug 2024 13:28:16 GMT
content-type: application/json
content-length: 0
cache-control: no-cache
link: <[GITLAB_URL]/api/v4/projects/zz%2Fxx%2Fyy%2Fxx%2Fyy/repository/tree?id=zz%2Fxx%2Fyy%2Fxx%2Fyy&page=2&pagination=legacy&per_page=20&recursive=true&ref=sonartest>; rel="next", <https://[GITLAB_URL]/api/v4/projects/zz%2Fxx%2Fyy%2Fxx%2Fyy/repository/tree?id=zz%2Fxx%2Fyy%2Fxx%2Fyy&page=1&pagination=legacy&per_page=20&recursive=true&ref=sonartest>; rel="first", <https://[GITLAB_URL]/api/v4/projects/zz%2Fxx%2Fyy%2Fxx%2Fyy/repository/tree?id=zz%2Fxx%2Fyy%2Fxx%2Fyy&page=41&pagination=legacy&per_page=20&recursive=true&ref=sonartest>; rel="last"
vary: Origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-gitlab-meta: {"correlation_id":"01J5THZBS1B80QE77N60F44DZ0","version":"1"}
x-next-page: 2
x-page: 1
x-per-page: 20
x-prev-page:
x-request-id: 01J5THZBS1B80QE77N60F44DZ0
x-runtime: 0.222422
x-total: 805
x-total-pages: 41
strict-transport-security: max-age=31536000
referrer-policy: strict-origin-when-cross-origin
- However, if I remove the “/repository/tree?recursive=true&ref=sonartest” suffix from the URL (which is what the WebIDE seems to be doing), I get a 500 error, even when using my PAT:
curl --header "PRIVATE-TOKEN: xxx-xxxxxxxxxxx-xx" "https://[GITLAB_URL]/api/v4/projects/zz%2Fxx%2Fyy%2Fxx%2Fyy" -I
HTTP/2 500
This suggests that the problem might not be with authentication, but with how the WebIDE is constructing its API calls or how the GitLab backend is handling requests for general project information. The fact that both the WebIDE and a direct curl command (when mimicking the WebIDE’s request structure) produce a 500 error indicates a server-side issue when trying to retrieve general project information.
We would appreciate any guidance on resolving this issue or further troubleshooting steps we should take.