Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. GitLab
  3. Bug: 500 Error when viewing files via direct link in GitLab web viewer

Bug: 500 Error when viewing files via direct link in GitLab web viewer

Scheduled Pinned Locked Moved Solved GitLab
7 Posts 4 Posters 1.1k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • timweddeT Offline
      timweddeT Offline
      timwedde
      wrote on last edited by
      #1

      I've recently been encountering this and figured I would report it here.

      This seems to occur because of how GitLab is packaged for Cloudron as I was unable to reproduce this issue on gitlab.com proper.
      However, I was able to trigger this issue on both Cloudrons I manage as well as on the official Cloudron GitLab instance as well.

      The error manifests when attempting to view a file via the built-in editor in GitLab. Navigating to a file via the interface works, but if you reload the file once it's open or alternatively navigate to its link directly, you will be greeted with a 500 error.

      Example link:
      https://git.cloudron.io/cloudron/gitlab-app/-/blob/master/README.md

      In the logs this manifests as such:

      Completed 500 Internal Server Error in 63ms (ActiveRecord: 3.7ms | Elasticsearch: 0.0ms | Allocations: 12843)
        
      ActionView::Template::Error (Can't find entry point 'monaco' in webpack manifest):
          2: - page_title @blob.path, @ref
          3: - signatures_path = namespace_project_signatures_path(namespace_id: @project.namespace.full_path, project_id: @project.path, id: @last_commit, limit: 1)
          4: - content_for :prefetch_asset_tags do
          5:   - webpack_preload_asset_tag('monaco', prefetch: true)
          6: 
          7: .js-signature-container{ data: { 'signatures-path': signatures_path } }
          8: 
      

      I found some things on the GitLab issue tracker about rebuilding frontend caches/packages but am not entirely sure how to achieve this (or whether it would actually help in this case) so any advice (or a potential fix) would be appreciated.

      nebulonN P 2 Replies Last reply
      3
      • timweddeT timwedde

        I've recently been encountering this and figured I would report it here.

        This seems to occur because of how GitLab is packaged for Cloudron as I was unable to reproduce this issue on gitlab.com proper.
        However, I was able to trigger this issue on both Cloudrons I manage as well as on the official Cloudron GitLab instance as well.

        The error manifests when attempting to view a file via the built-in editor in GitLab. Navigating to a file via the interface works, but if you reload the file once it's open or alternatively navigate to its link directly, you will be greeted with a 500 error.

        Example link:
        https://git.cloudron.io/cloudron/gitlab-app/-/blob/master/README.md

        In the logs this manifests as such:

        Completed 500 Internal Server Error in 63ms (ActiveRecord: 3.7ms | Elasticsearch: 0.0ms | Allocations: 12843)
          
        ActionView::Template::Error (Can't find entry point 'monaco' in webpack manifest):
            2: - page_title @blob.path, @ref
            3: - signatures_path = namespace_project_signatures_path(namespace_id: @project.namespace.full_path, project_id: @project.path, id: @last_commit, limit: 1)
            4: - content_for :prefetch_asset_tags do
            5:   - webpack_preload_asset_tag('monaco', prefetch: true)
            6: 
            7: .js-signature-container{ data: { 'signatures-path': signatures_path } }
            8: 
        

        I found some things on the GitLab issue tracker about rebuilding frontend caches/packages but am not entirely sure how to achieve this (or whether it would actually help in this case) so any advice (or a potential fix) would be appreciated.

        nebulonN Offline
        nebulonN Offline
        nebulon
        Staff
        wrote on last edited by
        #2

        @timwedde thanks for the report, with the directly link it is easy to reproduce. Indeed looks like a build or rebuild step which might be lacking in the package. We have to investigate.

        1 Reply Last reply
        2
        • nebulonN nebulon marked this topic as a question on
        • A Offline
          A Offline
          andreas
          wrote on last edited by
          #3

          @nebulon Is this error opening files in the GitLab editor also the same? I attached a video from our Cloudron GitLab instance.

          Recording

          1 Reply Last reply
          0
          • timweddeT timwedde

            I've recently been encountering this and figured I would report it here.

            This seems to occur because of how GitLab is packaged for Cloudron as I was unable to reproduce this issue on gitlab.com proper.
            However, I was able to trigger this issue on both Cloudrons I manage as well as on the official Cloudron GitLab instance as well.

            The error manifests when attempting to view a file via the built-in editor in GitLab. Navigating to a file via the interface works, but if you reload the file once it's open or alternatively navigate to its link directly, you will be greeted with a 500 error.

            Example link:
            https://git.cloudron.io/cloudron/gitlab-app/-/blob/master/README.md

            In the logs this manifests as such:

            Completed 500 Internal Server Error in 63ms (ActiveRecord: 3.7ms | Elasticsearch: 0.0ms | Allocations: 12843)
              
            ActionView::Template::Error (Can't find entry point 'monaco' in webpack manifest):
                2: - page_title @blob.path, @ref
                3: - signatures_path = namespace_project_signatures_path(namespace_id: @project.namespace.full_path, project_id: @project.path, id: @last_commit, limit: 1)
                4: - content_for :prefetch_asset_tags do
                5:   - webpack_preload_asset_tag('monaco', prefetch: true)
                6: 
                7: .js-signature-container{ data: { 'signatures-path': signatures_path } }
                8: 
            

            I found some things on the GitLab issue tracker about rebuilding frontend caches/packages but am not entirely sure how to achieve this (or whether it would actually help in this case) so any advice (or a potential fix) would be appreciated.

            P Offline
            P Offline
            plusone-nick
            wrote on last edited by
            #4

            @timwedde also noticed this after recent package update, was meaning to getting around to making a post on it. Thanks for the detailed report! +1

            ✌💙+1

            1 Reply Last reply
            0
            • nebulonN Offline
              nebulonN Offline
              nebulon
              Staff
              wrote on last edited by
              #5

              We have published a new app package with a fix for this.

              A timweddeT 2 Replies Last reply
              2
              • nebulonN nebulon has marked this topic as solved on
              • nebulonN nebulon

                We have published a new app package with a fix for this.

                A Offline
                A Offline
                andreas
                wrote on last edited by
                #6

                @nebulon Works. Thanks for the fast fix. 👍

                1 Reply Last reply
                1
                • nebulonN nebulon

                  We have published a new app package with a fix for this.

                  timweddeT Offline
                  timweddeT Offline
                  timwedde
                  wrote on last edited by
                  #7

                  @nebulon Can confirm as well, thanks for the quick turnaround!

                  1 Reply Last reply
                  1
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Bookmarks
                    • Search