search

openactive / open-booking-api

Repository for the Open Booking API specification
Other
2 stars 3 forks source link

Tentatively DELETE Order in rollback process for Booking that is halted at OrderCreationPaymentAuthorized #211

Open lukehesluke opened 3 years ago

lukehesluke commented 3 years ago

Proposer

IMIN LTD

Use Case

As a Booking System, I want to ensure that when an Order has been made in my system (during the B call) but there is an error in relaying this success to the Broker, that the Broker will DELETE this Order so that the space will not be filled up.

Here's an example scenario:

  1. Broker calls B in Booking System
  2. Booking System considers this a valid Order and saves it. According to this Booking System, the Order has been made and that space is filled up. Additionally, an amount of money is expected by them.
  3. Something happens that stops the Broker from receiving news of this success e.g.
    • Booking System immediately crashes and stays down so that even if Broker retries with exponential backoff, it will not receive the response
    • Booking System has a bug which means that while it saves the Order correctly, it simply fails in formulating the response back to Broker.
    • Broker immediately crashes
  4. At some point later, Broker sees that it has this Booking at OrderCreationPaymentAuthorized, so it commences this rollback process: https://openactive.io/open-booking-api/EditorsDraft/1.0CR3/#booking-halted-at-ordercreationpaymentauthorized.
  5. As this process does not include a step for Order Deletion, the Broker & the Customer considers the Order not to have happened, and the Booking System considers it to have happened. The Booking System is not paid and the space remains used up 😥

Why is this needed?

The current rollback flow at OrderCreationPaymentAuthorized does not include a step to delete the Order (in case it exists) and therefore, it could be left available as it is possible that it exists (see the scenario above) even though the creationStatus has not yet reached OrderCreationPaymentDue.

Proposal

Add, to the rollback flow at OrderCreationPaymentAuthorized, a step for the Broker to issue an Order Deletion as with the rollback flow at OrderCreationPaymentDue. The Broker should be instructed to happily ignore a 404 NotFoundError (as shown here) as there is only a small chance that it exists.

Example

In the example scenario in the above Use Case section, if the proposal was included, there would be a step 4.5, which DELETEs the Order. And therefore, step 5 does not occur.

nathansalter commented 3 years ago

Hi Luke, interesting scenario! I guess what I'm trying to understand is what benefit this actually provides the specification, but I think first I should just put down some of my thoughts and comments.

  1. Availability isn't necessarily related to bookings, but the Seller should always be the place where a Broker retrieves availability. It's sensible to assume that if a B request completes that availability should be decreased, but the availability information should as soon as possible get retrieved from the Seller's RPDE feed.
  2. If a B request is not placed, as in the B request either does not respond or fails, the Broker should be allowed to retry this request as they have no idea what state the Seller's booking system is in.
  3. Based on this part of the spec, the Broker shouldn't store the Order unless the B response succeeds, so having a method to delete this if it doesn't succeed doesn't make much sense
  4. This overall issue very much seems like it shouldn't be handled by the specification itself, as the process could be different per Seller as to the expected outcome if a failure like this happens.