[RTFACT-18349] An unexpected error occurs (e.g: NoMethodError undefined method `map' for nil:NilClass) When managing Ruby application's gem dependencies with bundler On Artifactory 6.7.0. Created: 24/Jan/19  Updated: 14/Aug/19  Resolved: 03/Feb/19

Status: Resolved
Project: Artifactory Binary Repository
Component/s: REST API
Affects Version/s: None
Fix Version/s: 6.8.0, 6.7.3

Type: Bug Priority: Blocker
Reporter: Sebastian Schmittner Assignee: Yoaz Menda (Inactive)
Resolution: Fixed Votes: 6
Labels: None

Issue Links:
Duplicate
duplicates RTFACT-18388 Bundle install failed when using loca... Resolved
is duplicated by RTFACT-18388 Bundle install failed when using loca... Resolved
is duplicated by RTFACT-18526 Ruby gems dependency error with Bundler Resolved
Relationship
relates to RTFACT-13635 Artifactory resets the connection whe... Resolved
Assigned QA: Barak Hacham
Sprint: Leap 37

 Description   

Description

An unexpected error occurs (e.g: NoMethodError undefined method `map' for nil:NilClass) When managing Ruby application's gem dependencies with bundler On Artifactory 6.7.0.

 

Steps to reproduce

$ bundle install --path ./test/bundle --verbose

If you need to re-run above command with change of Gemfile as following, you need to delete Gemfile.lock which will be created only in case gems are installed successfully.

1) When source indicate to gems-local

Gemfile

~~~~~~~ 

source 'https://rubygems.org/'

source 'http://127.0.0.1:8081/artifactory/api/gems/gems-local/'

gem 'sfn'

~~~~~~~~

==> this will works

Bundle complete! 1 Gemfile dependency, 39 gems now installed.

Bundled gems are installed into `./test/bundle`

You may need to delete Gemfile.lock at this time.

2) When source indicate to gems-remote

Gemfile

~~~~~~~ 

source 'https://rubygems.org/'

source 'http://127.0.0.1:8081/artifactory/api/gems/gems-remote/'

gem 'sfn'

~~~~~~~ 

 ==> This will fail due to remote repo of gems-remote as following errors.

Retrying dependency api due to error (2/4): NoMethodError undefined method `map' for nil:NilClass

Did you mean?  tap

Retrying dependency api due to error (3/4): NoMethodError undefined method `map' for nil:NilClass

Did you mean?  tap

Retrying dependency api due to error (4/4): NoMethodError undefined method `map' for nil:NilClass

Did you mean?  tap

Retrying fetcher due to error (2/4): NoMethodError undefined method `map' for nil:NilClass

Did you mean?  tap

Unfortunately, an unexpected error occurred, and Bundler cannot continue.

3) When source pointing to virtual repo such as gems

Gemfile

~~~~~~~ 

source 'https://rubygems.org/'

source 'http://127.0.0.1:8081/artifactory/api/gems/gems/'

gem 'sfn'

~~~~~~~

 ==> This will fail due to remote repo in side of gems virtual repository

Retrying dependency api due to error (2/4): NoMethodError undefined method `map' for nil:NilClass

Did you mean?  tap

Retrying dependency api due to error (3/4): NoMethodError undefined method `map' for nil:NilClass

Did you mean?  tap

Retrying dependency api due to error (4/4): NoMethodError undefined method `map' for nil:NilClass

Did you mean?  tap

Retrying fetcher due to error (2/4): NoMethodError undefined method `map' for nil:NilClass

Did you mean?  tap

Unfortunately, an unexpected error occurred, and Bundler cannot continue.

 



 Comments   
Comment by J. [ 29/Jan/19 ]

Same issue here. All other repo's work after the patch except the Ruby Gems API endpoint. 404 not found.

Comment by Dan Feldman [ 29/Jan/19 ]

/api/gems/{repo_key} Is not a path that Artifactory responds to (or ever has).

The fact that the same endpoint works for npm is specific to client implementation (which is why Artifactory answers there).

 

If you're having specific issues with the gems client please post logs from Artifactory and the client's debug print so we can identify what endpoints are having issues.

Comment by J. [ 29/Jan/19 ]

In the 'Set Me Up' instructions for connecting with the Ruby repo it says:

 

gem source -a http://<USERNAME>:<PASSWORD>@%{FQDN}/artifactory/api/gems/rubygems/

This endpoint did work before the update. After the update I get (we haven't changed anything except upgraded Artifactory):

curl http://${USER}:${PASS}@${FQDN}/api/gems/rubygems/

HTTP/1.1 404 Not Found

"errors" : [ {
  "status" : 404,
  "message" : "Not Found"
} ]

Where rubygems is our repo-name.

 

Comment by J. [ 29/Jan/19 ]

Forgot to add /artifactory after the FQDN in the previous example, still the 404. So no mistakes there

Comment by Sander Cornelissen [ 30/Jan/19 ]

The real problem we have (J. is a colleage) is described in RTFACT-18388. The curl is probably correct that it returns a 404. But bundler failed when resolving depdendencies, that is our real problem. J. thought that that was related to a 404 on given URL, but it's not.

Comment by Omer Haglili [ 30/Jan/19 ]

Workaround for version 6.7.0 and above:

Add the below system property(the goal of this property is to allow caching dependency requests)

In order to apply the workaround edit the $ARTIFACTORY_HOME/etc/artifactory.system.properties file by and add the following value:

artifactory.gems.remoteAllowCacheDependencies=false

**Note a restart is required to apply the changes.

Comment by Sebastian Schmittner [ 30/Jan/19 ]

Well, the 404 issue was wrong, from our side. But the issue persisted.
Because we did not get feedback from JFrog earlier we restored a backup and will stay on 6.6.5 for the time being.

Comment by Sander Cornelissen [ 30/Jan/19 ]

Actually, the issue is now updated with content from RTFACT-18388. Should RTFACT-18388 be cosed now?

Comment by Adam Crews [ 30/Jan/19 ]

On my system, when implementing the workaround noted above, I no longer receive the map errors, however, after 40+ minutes of letting a `bundle install` run, it is still resolving dependencies.  So this is still effectively broken in my setup even with the workaround.

Comment by David Morse [ 03/Feb/19 ]

After upgrading to 6.7.2 I ran a bundle install and still get the same error when trying to pull from a virtual repo:

Retrying dependency api due to error (2/4): NoMethodError undefined method `map' for nil:NilClass

Retrying dependency api due to error (3/4): NoMethodError undefined method `map' for nil:NilClass

Retrying dependency api due to error (4/4): NoMethodError undefined method `map' for nil:NilClass

Retrying fetcher due to error (2/4): NoMethodError undefined method `map' for nil:NilClass
.
Retrying fetcher due to error (3/4): NoMethodError undefined method `map' for nil:NilClass
.
Retrying fetcher due to error (4/4): NoMethodError undefined method `map' for nil:NilClass
Comment by Adam Crews [ 03/Feb/19 ]

I also upgraded to 6.7.2, and have the same issues as David.  I have re-implemented the workaround noted by Omer, and this time around, I am able to successfully install gems that have dependencies.

Comment by Shlomi Kriheli [ 04/Feb/19 ]

Hi David Morse, Adam Crews,

The fix was accidentally not pushed to version 6.7.2.
We will release Artifactory 6.7.3 in the next couple of days that will contain the fix for this issue. 

My apologies for the confusion here. 

 

Comment by David Morse [ 06/Feb/19 ]

After talking with support it looks like the changes didn't merge into 6.7.2.  They released 6.7.3 and I upgraded and the problem has gone away.  

Comment by Adam Crews [ 06/Feb/19 ]

I still see the error with 6.7.3.  David Morse Do you have the the workaround Omer mentioned above applied?  When I apply that workaround, bundle install completes successfully, but if I remove that setting, the map errors from bundler return.

Comment by David Morse [ 06/Feb/19 ]

I removed the workaround and just verified on the prod servers.  6.7.3 is working for me without the work around

Comment by Josh Basch [ 07/Feb/19 ]

I also ran into this issue. Just updated to 6.7.3 and the problem did not go away immediately. I had to delete content in the cache repos for the remotes that were associated with the virtual repo I was trying to resolve dependencies from. Adam Crews does doing that also fix it for you?

Comment by Adam Crews [ 07/Feb/19 ]

Thanks for the tip Josh Basch, clearing the cache fixed it all up.  Thx Jfrog for getting this resolved.

Generated at Sun Oct 20 11:12:08 UTC 2019 using JIRA 7.6.16#76018-sha1:9ed376192612a49536ac834c64177a0fed6290f5.