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.3k 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