BKG 2.0: SD-2712: Clear the bookingCancellationStatus

[HenrikHL]

User description

SD-27129: Update GET endPoint (and any other place) to make it clear the bookingCancellationStatus is ALSO cleared

---

PR Type

Documentation

---

Description

• Clarifies bookingCancellationStatus lifecycle in GET endpoint documentation

• Documents when cancellation status is cleared during amendments and re-confirmations

• Updates polling description to include bookingCancellationStatus monitoring

• Explains provider's ability to decline booking cancellations

---

Diagram Walkthrough

flowchart LR
  A["Booking Cancelled"] -->|"Provider declines"| B["bookingCancellationStatus = CANCELLATION_DECLINED"]
  B -->|"Re-confirm or amend"| C["bookingCancellationStatus cleared"]
  A -->|"Provider approves"| D["Cancellation processed"]
  B -->|"GET endpoint"| E["Status visible in payload"]
  C -->|"GET endpoint"| F["Status no longer accessible"]

Loading

File Walkthrough

Relevant files

Documentation

BKG_v2.0.4.yaml Document bookingCancellationStatus lifecycle and clearing bkg/v2/BKG_v2.0.4.yaml Added documentation explaining bookingCancellationStatus is included in both payloads when cancellation is attempted Documented that cancellation status is cleared when provider re-confirms booking or consumer requests amendment Updated polling description to explicitly mention bookingCancellationStatus as a detectable change Clarified that re-confirming or amending a booking "clears" the bookingCancellationStatus +6/-2

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟢	🎫 #SD-2712 🟢 Update the GET endpoint documentation to make it clear that bookingCancellationStatus is also cleared. Ensure any other relevant documentation/place also states bookingCancellationStatus is cleared when UC6, UC7, or a Booking is re-confirmed.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Correct inconsistent use case reference Correct the inconsistent documentation for bookingCancellationStatus. The documentation mentions both UseCase 6 and UseCase 7 as clearing the status in different places; it should be made consistent. bkg/v2/BKG_v2.0.4.yaml [1133-1135] -+ The status of a cancellation of the Booking is included in both payloads as `bookingCancellationStatus` in case an attempt to cancel the booking has been made. It is only available after the provider has approved the `Booking` via **UseCase 5: Confirm Booking request** and until: -+ - the provider requests for a new amendment (**UseCase 6: Request to amend confirmed Booking**) in which case the "old status" is no longer accessible. -+ - the provider re-confirms the `Booking` (**UseCase 5: Confirm booking request**) in which case the "old status" is not "carried over" and will no longer be accessible. +The status of a cancellation of the Booking is included in both payloads as `bookingCancellationStatus` in case an attempt to cancel the booking has been made. It is only available after the provider has approved the `Booking` via **UseCase 5: Confirm Booking request** and until: +- the consumer submits a new amendment (**UseCase 7: Request amendment to confirmed Booking**) in which case the "old status" is no longer accessible. +- the provider re-confirms the `Booking` (**UseCase 5: Confirm booking request**) in which case the "old status" is not "carried over" and will no longer be accessible. [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies a critical inconsistency in the API documentation between two different sections regarding which use case clears the bookingCancellationStatus, which could lead to confusion for API consumers.	Medium
	✅ Restore accidentally removed documentation Suggestion Impact: The commit re-added the missing documentation sentence about `amendedContent=true` returning `404` when no amendment has been provided or the original booking is in `PENDING_AMENDMENT`. code diff: + + If `amendedContent=true` is requested but no amendment has yet been provided by the consumer **or** the state of the "original" `Booking` is `PENDING_AMENDMENT`, then a `404` (Not Found) is returned. Restore the line of documentation describing the behavior for amendedContent=true, as it appears to have been removed accidentally. bkg/v2/BKG_v2.0.4.yaml [1133-1135] -- If `amendedContent=true` is requested but no amendment has yet been provided by the consumer **or** the state of the "original" `Booking` is `PENDING_AMENDMENT`, then a `404` (Not Found) is returned. -+ The status of a cancellation of the Booking is included in both payloads as `bookingCancellationStatus` in case an attempt to cancel the booking has been made. It is only available after the provider has approved the `Booking` via **UseCase 5: Confirm Booking request** and until: -+ - the provider requests for a new amendment (**UseCase 6: Request to amend confirmed Booking**) in which case the "old status" is no longer accessible. -+ - the provider re-confirms the `Booking` (**UseCase 5: Confirm booking request**) in which case the "old status" is not "carried over" and will no longer be accessible. +- the provider re-confirms the `Booking` (**UseCase 5: Confirm booking request**) in which case the "old update" is no longer accessible. +The status of a cancellation of the Booking is included in both payloads as `bookingCancellationStatus` in case an attempt to cancel the booking has been made. It is only available after the provider has approved the `Booking` via **UseCase 5: Confirm Booking request** and until: +- the consumer submits a new amendment (**UseCase 7: Request amendment to confirmed Booking**) in which case the "old status" is no longer accessible. +- the provider re-confirms the `Booking` (**UseCase 5: Confirm booking request**) in which case the "old status" is not "carried over" and will no longer be accessible. + +If `amendedContent=true` is requested but no amendment has yet been provided by the consumer **or** the state of the "original" `Booking` is `PENDING_AMENDMENT`, then a `404` (Not Found) is returned. + [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that a line of documentation about amendedContent=true was likely removed by mistake, and its restoration would improve the completeness of the API specification.	Medium
Update

[Copilot]

Pull request overview

This PR updates API documentation to clarify the lifecycle of bookingCancellationStatus, specifically documenting when this status field is cleared during the booking amendment and re-confirmation processes.

Changes:

• Documented that bookingCancellationStatus is cleared when providers re-confirm bookings or consumers request amendments
• Updated polling endpoint description to include bookingCancellationStatus as a monitored field
• Added explanation of when cancellation status is accessible vs. cleared

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The phrase 'requests for a new amendment' contains awkward phrasing. It should be 'requests a new amendment' for clarity.

[Copilot]

The reference 'UseCase 5: Confirm booking request' uses inconsistent capitalization compared to 'UseCase 6: Request to amend confirmed Booking' on line 1136. For consistency, it should be 'Confirm Booking request' to match the pattern established in the other use case references.