Open knight-dj-et opened 9 years ago
@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.
The Duplicate Provision check is only run if
!api_requires?("many_per_app")
(if the manifest does not specifymany_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.