Allow Broker to ignore irrelevant updates when listening for Order/Opportunities (Listener Item Expectations)

[lukehesluke]

Example Scenario

this is a scenario which we have seen with an organization attempting to pass Test Suite on their booking system

1. Run Seller Requested Cancellation on an Order with multiple OrderItems. The test has invoked the SellerRequestedCancellationSimulateAction and is waiting for a change to the Orders RPDE feed (using Broker's /order-listeners/:type/:bookingPartnerIdentifier/:uuid endpoint)
2. Booking System's processes are set up in such a way that it cancels each OrderItem one at a time
3. Boker sees the first change to the Orders RPDE feed in which just one of the OrderItems is designated as cancelled and passes this back to Test Suite
4. Test Suite fails validation as only one of the OrderItems is cancelled and it was expecting all to be.

A possible solution

Suppose Broker was given instructions on what kind of updates it should expect to see, and so what it can ignore. Then, in the above scenario, Broker would ignore the first Orders RPDE feed update, because it's expecting to see all OrderItems be cancelled. It would keep ignoring them until it finds an update which sets all to cancelled. Then, the test would pass.

Proposed name for this set of instructions on what kinds of item to wait for: Listener Item Expectations

Refactoring

It's also worth considering, when implementing this, if the expectedCapacity mechanism, which is used for "Assert Opportunity Capacity after X" tests, show now just use the Listener Item Expectations functionality.

One caveat is that it should not be possible to turn off, via configuration, this particular expectation, as it is essential for many tests e.g. asserting that capacity decrements after a lease or successful booking and that it decrements after removing a lease, cancelling a booking, etc.

Potential issues

I would not want to implement something like this until RPDE tracing (#665) has been implemented.

If we implemented this without RPDE tracing then this is what would happen when a user has a test failure (using again a Seller Requested Cancellation test example):

1. Test Suite invokes SellerRequestedCancellationSimulateAction and asks Broker to listen for the Orders RPDE feed change, which should have OrderItems set to seller-cancelled.
2. Broker sees something in the Orders RPDE feed which is incorrect and ignores it
3. Then, Broker times out
4. The user looks at the Test Suite results and just sees ESOCKETTIMEDOUT and has no clue what they did wrong

When we have RPDE tracing, we could have the Test Suite results include info about each update that was found and why it was ignored if it was.

Work so far

The Possible Solution has now been implemented for Seller Requested Cancellations (#699) and Customer-Requested Cancellations (#700). Further PRs would be needed to also enable it for other features.

The rule is that this will need to be implemented for every test which:

• Waits for an Order Feed update after the successful conclusion of some action (e.g. cancellation or access pass update)