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
  • Brite
  • 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 - Status | 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 2.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

                Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                With your input, this post could be even better 💗

                Register Login
                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