Fix HTTP status codes to match Design Guide semantics (#48) - #56
Merged
Conversation
DLondonoD
requested review from
FabrizioMoggio,
JoseMConde,
Kevsy,
gainsley,
maheshc01 and
seralogar
as code owners
July 21, 2026 13:34
seralogar
reviewed
Jul 28, 2026
Comment on lines
+717
to
+720
| "403": | ||
| $ref: "../common/CAMARA_common.yaml#/components/responses/Generic403" | ||
| "410": | ||
| $ref: "../common/CAMARA_common.yaml#/components/responses/Generic410" | ||
| "404": | ||
| $ref: "../common/CAMARA_common.yaml#/components/responses/Generic404" |
Contributor
There was a problem hiding this comment.
The 200 above documents an empty list for the no-match case, so a 404 here contradicts it. Every other 404 in this file is on a by-id operation, and #58 adds GET /deployments/{appDeploymentId} where it is unambiguous. Suggest dropping it and keeping the 410 removal.
Suggested change
| "403": | |
| $ref: "../common/CAMARA_common.yaml#/components/responses/Generic403" | |
| "410": | |
| $ref: "../common/CAMARA_common.yaml#/components/responses/Generic410" | |
| "404": | |
| $ref: "../common/CAMARA_common.yaml#/components/responses/Generic404" | |
| "403": | |
| $ref: "../common/CAMARA_common.yaml#/components/responses/Generic403" |
GET /deployments is a collection endpoint whose 200 response already documents an empty list for the no-match case, so adding 404 contradicted it. 404 remains appropriate only for by-id lookups. Addresses review comment from @seralogar on PR camaraproject#56.
seralogar
approved these changes
Jul 29, 2026
DLondonoD
added a commit
to DLondonoD/EdgeApplicationManagement
that referenced
this pull request
Jul 29, 2026
getAppDeployments, deleteAppDeployment and updateAppDeployment no longer document 410 in the spec since the fix in camaraproject#48/camaraproject#56 (410 is now scoped to the notification/callback flow only). These 3 .feature files still had leftover '410 GONE' scenarios asserting a response code the operations never return.
DLondonoD
added a commit
to DLondonoD/EdgeApplicationManagement
that referenced
this pull request
Jul 31, 2026
Commit 725880e applied seralogar's suggestion to change deleteApp's 409 $.code from ABORTED to INCOMPATIBLE_STATE (per camaraproject#56, ABORTED is now only correct for updateAppDeployment's 409), but the scenario tag was not part of that suggestion diff. Renaming @eam_deleteApp_409.1_aborted -> @eam_deleteApp_409.1_incompatible_state to match, as also requested in the same review comment.
This was referenced Jul 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
correction
What this PR does / why we need it:
Aligns three error-code choices in the EAM API with the semantics defined
in the CAMARA API Design Guide (section 3.2.1):
deleteApp(DELETE /apps/{appId}): changes the409code fromABORTEDtoINCOMPATIBLE_STATE.ABORTEDis defined forconcurrent-modification conflicts, but this case — a delete blocked
because a referenced running instance still exists — matches
INCOMPATIBLE_STATEinstead./deploymentsCRUD operations: removes410 GONEfromgetAppDeployments(GET),deleteAppDeployment(DELETE) andupdateAppDeployment(PATCH). The Design Guide and this API's ownGeneric410response template scope410to the notification/callbackflow only (correctly used by
onAppInstanceStatusChangeandonAppDeploymentStatusChange, left untouched).GET /deploymentsnowuses
404for the no-match case (previously had neither);DELETE/PATCHalready declared
404, so the redundant410was simply dropped.submitApp,createAppInstance,createAppDeployment: removes501 NOT_IMPLEMENTED. The Design Guide says501usage should beavoided and reserved for genuinely optional endpoints; none of these
three creation operations state a justification for being optional.
Which issue(s) this PR fixes:
Fixes #48
Special notes for reviewers:
No runtime/behavioral change — this only corrects which error codes are
documented in the spec to align with the Design Guide's standardized
error-response semantics. Callback
410usage (notification flow) wasintentionally left as-is since it already matches the Guide.
Changelog input
release-note Fix deleteApp 409 code (ABORTED to INCOMPATIBLE_STATE), remove 410 from plain /deployments CRUD operations,
and remove unjustified 501 from creation operations, per Design Guide error-response semantics.
Additional documentation
This section can be blank.
docs