Uploaded image for project: 'Dev - Nexus Repo'
  1. Dev - Nexus Repo
  2. NEXUS-20429

incomplete gem metadata returned sometimes

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.16.1, 3.21.1
    • Fix Version/s: None
    • Component/s: RubyGems
    • Labels:

      Description

      We have a large number of build jobs that use Bundler to fetch and setup our expected gem versions from Nexus. We've seen a few intermittent build failures recently that complain a certain gem isn't in Nexus, but we've ensured that it is. We're thinking this might be related to Nexus returning bad or incomplete metadata.

      Error:

      Fetching gem metadata from https://nexus.engine.sourcefire.com/repository/gems/.........Your bundle is locked to docile (1.3.1), but that version could not be found in any of the sources listed in your Gemfile. If you haven't changed sources, that means the author of docile (1.3.1) has removed it. You'll need to update your bundle to a version other than docile (1.3.1) that hasn't been removed in order to install.

       
      We were able to correlate this error to the following Nexus request:

      10.85.106.255 - - [04/Jul/2019:21:11:14 +0000] "GET /repository/gems/api/v1/dependencies?gems=clamp%2Ccoderay%2Ccolorize%2Cdiff-lcs%2Cdocile%2Cdotenv%2Cffi%2Cfpm%2Cgit%2Cinsist%2Cipaddress%2Cmemoist%2Cmethod_source%2Cmini_portile2%2Cmixlib-cli%2Cmustache%2Cnet-ssh%2Cnokogiri%2Cohai%2Cparser%2Cpleaserun%2Cpowerpack%2Cpry%2Cpry-byebug%2Crainbow%2Crb-readline%2Crspec%2Crspec-core%2Crspec-expectations%2Crspec-mocks%2Crspec-support%2Crubocop%2Cruby-progressbar%2Cruby-xz%2Csimplecov%2Csimplecov-html%2Cstud%2Csvcr%2Csystem%2Csystemu%2Cunicode-display_width%2Cversion%2Cyajl-ruby HTTP/1.0" 200 - 14413 181 "bundler/1.16.5 rubygems/2.7.6 ruby/2.5.1 (x86_64-pc-linux-gnu) command/install options/no_install,bin,build.nokogiri,path dc786c03e93c1be6"

       
      Notice the size of the request: 14413 bytes
      Looking through the logs for successful requests the request size is (almost) always 325065 bytes.
       
      Capturing a full copy of the metadata using the path in the above request log gives us a data file that contains all of the expected versions of the docile gem:

      docile

      1.1.5

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      1.1.1

      docile

      1.0.5

      docile

      1.0.2

      docile

      1.1.0

      docile

      1.1.4

      docile

      1.3.0

      docile

      0.9.1

      docile

      1.1.3

      docile

      1.0.3

      docile

      1.1.2

      docile

      1.0.4

      docile

      1.3.1

      docile

      1.0.1

      docile

      1.3.2

      docile

      1.2.0

      docile

      0.9.2

      docile

      0.9.0

      docile

      1.0.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1

      docile

      ~> 1.1.0

      docile

      ~> 1.1

      docile

      ~> 1.1.0

      docile

      ~> 1.1

       
       
      We wrote a simple bash loop to run this request every 30 seconds over night and were able to get the smaller metadata data file twice. Looking through this file it is indeed missing the expected version of docile:

      docile

      1.1.5

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

      docile

      ~> 1.1.0

       
      Have you guys seen anything like this before? We don't have any cleanup policies defined and I don't see any cronjobs on the server that ran around when the request returned the shorter result. Attaching the normal and small metadata files.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            flevesqu Francis Levesque
            Last Updated By:
            Joe Tom Joe Tom
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Date of First Response:

                tigCommentSecurity.panel-title