Problem description
The releaseDevices operation (POST /qos-bookings/{bookingId}/devices/release) currently returns assignmentStatus: SUCCESSFUL when devices are successfully released. This is identical to the status returned by assignDevices when devices are successfully assigned.
A consumer that processes both assignment and release callbacks (or polling responses) cannot determine from assignmentStatus alone whether the operation that completed was an assignment or a release. They must inspect the optional statusInfo field for values like ASSIGNMENT_COMPLETED vs DEVICE_RELEASED — relying on undocumented inference from secondary data, which CAMARA Design Guide §3.1.2 explicitly prohibits.
Possible evolution
A distinct RELEASED value should be added to AssignmentStatus and AssignmentStatusChanged to unambiguously represent the completion of a release operation. Consumers can then branch on assignmentStatus alone:
ASSIGNED → all requested devices are now assigned to the booking (changing SUCCESSFUL TO ASSIGNED)PARTIAL_SUCCESS → assignment or release completed partiallyRELEASED → release operation completed; devices are no longer assigned (changing SUCCESSFUL to ASSIGNED)FAILURE → the operation failed
Alternative solution
Additional context
- Affected schemas:
AssignmentStatus, AssignmentStatusChanged
- Affected operations:
releaseDevices (POST /qos-bookings/{bookingId}/devices/release) for synchronous responses; EventAssignmentStatusChanged for async callbacks
- Affected example:
ASSIGNMENT_RELEASED — previously showed assignmentStatus: SUCCESSFUL, statusInfo: ASSIGNMENT_COMPLETED; should show assignmentStatus: RELEASED, statusInfo: DEVICE_RELEASED
AssignmentStatusInfo also requires a new DEVICE_RELEASED value to complement RELEASED- CAMARA Design Guide reference: §3.1.2 Core Principles — "APIs MUST NOT rely on undocumented inference from missing data"; §3.1.3 Recommended Modeling Pattern — "a domain-specific primary outcome field representing the business result" should be self-describing without secondary field inspection
Problem description
The
releaseDevicesoperation (POST /qos-bookings/{bookingId}/devices/release) currently returnsassignmentStatus: SUCCESSFULwhen devices are successfully released. This is identical to the status returned byassignDeviceswhen devices are successfully assigned.A consumer that processes both assignment and release callbacks (or polling responses) cannot determine from
assignmentStatusalone whether the operation that completed was an assignment or a release. They must inspect the optionalstatusInfofield for values likeASSIGNMENT_COMPLETEDvsDEVICE_RELEASED— relying on undocumented inference from secondary data, which CAMARA Design Guide §3.1.2 explicitly prohibits.Possible evolution
A distinct
RELEASEDvalue should be added toAssignmentStatusandAssignmentStatusChangedto unambiguously represent the completion of a release operation. Consumers can then branch onassignmentStatusalone:ASSIGNED→ all requested devices are now assigned to the booking (changing SUCCESSFUL TO ASSIGNED)PARTIAL_SUCCESS→ assignment or release completed partiallyRELEASED→ release operation completed; devices are no longer assigned (changing SUCCESSFUL to ASSIGNED)FAILURE→ the operation failedAlternative solution
Additional context
AssignmentStatus,AssignmentStatusChangedreleaseDevices(POST /qos-bookings/{bookingId}/devices/release) for synchronous responses;EventAssignmentStatusChangedfor async callbacksASSIGNMENT_RELEASED— previously showedassignmentStatus: SUCCESSFUL,statusInfo: ASSIGNMENT_COMPLETED; should showassignmentStatus: RELEASED,statusInfo: DEVICE_RELEASEDAssignmentStatusInfoalso requires a newDEVICE_RELEASEDvalue to complementRELEASED