Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

version.locked? method returns incorrect value of true for unlocked version #47

Closed
jondade opened this issue Jan 20, 2015 · 3 comments
Closed

Comments

@jondade
Copy link

jondade commented Jan 20, 2015

When calling Version.locked? on an unlocked / freshly cloned version the response is always true regardless of actual state.

The only time this is not true is if the version was created / cloned by this instance of Fastly.

@eddieroger
Copy link
Contributor

eddieroger commented May 27, 2016

I just noticed that some of my upload scripts are behaving the same way, where getting the latest version shows that it's unlocked, but when I inspected the service.versions response, it appears to be locked. For example:

2.2.3 :025 > service.versions.last.locked?
 => false
2.2.3 :026 > service.versions.last.number
 => 387

But when I look at service.versions, I see the last version is marked as locked:

{"testing"=>false, "locked"=>true, "number"=>387, "active"=>true, "service_id"=>"[my_service]", "staging"=>false, "created_at"=>"2016-05-26T03:33:51+00:00", "deleted_at"=>nil, "comment"=>"", "updated_at"=>"2016-05-26T03:34:08+00:00", "deployed"=>false}

Haven't done more digging than that, but I'm seeing the same behavior and am glad it's not just me. Creating a new clone in the Fastly UI was how I got the upload scripts to work again for me as well.

Edited to add that I'm seeing this on gem version 1.4.2 on both a Mac and CentOS, not that I think the OS matters all that much.

@eddieroger
Copy link
Contributor

One more thing (I promise to start coalescing my updates 😄 ) - when calling the API directly, the version is returned as locked. I looked through the history of Version.rb, and right before this ticket was made, a commit removed :locked from attr_accessor, which I think is causing problems with the new logic more recently added. I went in to my local gem source and added :locked back to the attr_accessor line, and sure enough v.locked? worked for me again.

Here's the commit where it was removed:

ebbfb3c

And my irb after I modified my local gem source:

2.2.3 :021 > v.locked?
 => true
2.2.3 :022 > v.number
 => 389

Corresponding API call:

        {
            "active": true,
            "comment": "",
            "created_at": "2016-05-27T12:49:34+00:00",
            "deleted_at": null,
            "deployed": false,
            "locked": true,
            "number": 389,
            "service_id": "[my service]",
            "staging": false,
            "testing": false,
            "updated_at": "2016-05-27T12:50:08+00:00"
        }

@lanej
Copy link
Contributor

lanej commented Jun 17, 2016

Fixed by #83 #81

@lanej lanej closed this as completed Jun 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants