Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Duplicate Provision Issue #89

Open
knight-dj-et opened this issue Jul 13, 2015 · 1 comment
Open

Duplicate Provision Issue #89

knight-dj-et opened this issue Jul 13, 2015 · 1 comment

Comments

@knight-dj-et
Copy link

The Duplicate Provision check is only run if !api_requires?("many_per_app") (if the manifest does not specify many_per_app; however, inside the actual check class, the opposite condition is found (if api_requires?("many_per_app")), which can never be true when reached. Thus, the error message "multiple provisions cannot return the same id" will never occur.

In any case, the Heroku apps are unclear on how an add-on should respond to a duplicate provision request. Wouldn't Heroku prevent provisioning the same add-on multiple times if the add-on does not allow many_per_app? I was planning to directly use the UUID for the returned Id since we do not allow many_per_app, yet kensa tests the same provision data.

@bjeanes
Copy link
Contributor

bjeanes commented Jul 13, 2015

@knight-dj-et definitely sounds like a bug. I think the test should always run personally.

Wouldn't Heroku prevent provisioning the same add-on multiple times if the add-on does not allow many_per_app?

Yes. Though it's possible for us to send a provision request while the provider side still think the add-on is provisioned (a race condition due to de-provision being async). This test is designed to ensure that the provider accommodates that correctly.

I was planning to directly use the UUID for the returned Id since we do not allow many_per_app, yet kensa tests the same provision data

Using the UUID is fine. kensa is pretty naive.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants