Test failing but specifying the same `plan_id`

[mattmcneeney]

When running the -binding test suite, the following test is failing:

╷
└─ JUnit Jupiter ✔
   └─ Binding Tests ✔
      └─ Valid Provision and Binding Tests. ✔
         ├─ Running a valid provision and run binding tests. Delete both afterwards. In case of a asynchronous service broker polling after each operation. ✔
         │  ├─ Creating Service Instance, and try to fetch it. ✔
         │  │  ├─ Running valid PUT provision with instanceId c8968e6e-ca9f-4853-964a-c0f88bda3c00 for service 'overview-service' and plan 'small' ✔
         │  │  ├─ Running valid PUT provision with same attributes again. Expecting Status 200. ✔
         │  │  └─ Running valid PUT provision with different plan_id again. Expecting Status 409. ✘ 1 expectation failed.
         │  │           Expected status code one of {<409>} but was <200>.

However, when I check the logs for the broker, I can see that the three corresponding provision requests:

Creating service instance c8968e6e-ca9f-4853-964a-c0f88bda3c00 using service 33ceba5779bfa320a1ef0694d98069df and plan e8a882786ba9e223187be22c64a8720e
Creating service instance c8968e6e-ca9f-4853-964a-c0f88bda3c00 using service 33ceba5779bfa320a1ef0694d98069df and plan e8a882786ba9e223187be22c64a8720e
Creating service instance c8968e6e-ca9f-4853-964a-c0f88bda3c00 using service 33ceba5779bfa320a1ef0694d98069df and plan e8a882786ba9e223187be22c64a8720e

However, the third provision request is supposed to contain a different plan_id, and hence the test expects a 409 status code. It seems like the broker is receiving the same plan_id on all three requests, and hence returns a 200 status code.

Could you check whether this is a bug in the test suite for me?

[chbrinker]

Hi Matt,

in our pipelines the test is green. I will double check it with the checkers code. But our service brokers send a 409 there.

[mattmcneeney]

Interesting. I wonder if this is to do with the application.yml? I don't specify any services/plans because I expect the full catalog to be used:

##Define the service broker connection here
config:
  url: http://localhost
  port : 3000
  apiVersion: 2.15
  user: admin
  password: password

[mattmcneeney]

This is the broker I'm using in case you want to have a go: https://github.com/cloudfoundry/overview-broker

[joStrauss]

Hi Matt, Thanks for raising this. My logs are wrong here. It's not swapping the plan_id, but the space_guid and org_guid, as this was the simpler solution to force a conflict statusCode in compliance with the spec. This means your Service Broker is not checking if these fields are correct.

Only for bindings, the plan_id is changed, if there are multiple plans defined inside the catalog because there are no other mandatory fields than service_id and plan_id. When implementing this, I must have broken the logs. Sorry about that.

@chbrinker We could add checks that verify a 409 with different plan_id and the other fields each. Any thoughts?

[mattmcneeney]

Ah good spot!

You're right that my broker doesn't check these fields. I can add a check, but given that the organization_guid and space_guid fields are deprecated, it might be worth changing this test to change the service_id or plan_id field.

[joStrauss]

I think it would be better to make this API-version dependent feature since these fields are still considered mandatory.