fix: align API status codes with OpenAPI specs#1056
Conversation
Update 5 mutation endpoints that were returning 200 instead of 202 (Accepted) as declared in the OpenAPI jsonnet specs:
- PATCH /deploymentversions/{deploymentVersionId}
- POST /deployments/{deploymentId}/versions
- DELETE /relationship-rules/{relationshipRuleId}
- PUT /relationship-rules/{relationshipRuleId}
- DELETE /resources/identifier/{identifier}
Co-authored-by: Aditya Choudhari <adityachoudhari26@users.noreply.github.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 46 minutes and 41 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Aligns several workspace mutation endpoints in apps/api to return HTTP 202 Accepted as declared by the OpenAPI Jsonnet/spec output, addressing a client-generation breaking mismatch reported in #1011.
Changes:
- Updated 5 mutation endpoints to respond with
202instead of200. - Kept response payloads the same while changing only the HTTP status codes.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| apps/api/src/routes/v1/workspaces/resources.ts | Return 202 Accepted for delete-by-identifier resource mutation. |
| apps/api/src/routes/v1/workspaces/relationship-rules.ts | Return 202 Accepted for relationship-rule delete + upsert mutations. |
| apps/api/src/routes/v1/workspaces/deployments.ts | Return 202 Accepted for “create deployment version” mutation. |
| apps/api/src/routes/v1/workspaces/deployment-versions.ts | Return 202 Accepted for deployment-version patch mutation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| enqueueRelationshipReconciliation(workspaceId); | ||
|
|
||
| res.status(200).json({ id: relationshipRuleId }); | ||
| res.status(202).json({ id: relationshipRuleId }); |
There was a problem hiding this comment.
The DELETE /relationship-rules/{relationshipRuleId} handler now returns 202, which matches the OpenAPI status code, but the response body still only includes { id }. OpenAPI declares the 202 response schema as RelationshipRule (required fields include name/reference/cel/metadata/workspaceId), so generated clients will likely fail to decode this response. Return the deleted rule (e.g., using the already-fetched rule + toRuleResponse) or update the OpenAPI spec to match the { id } payload.
| res.status(202).json({ id: relationshipRuleId }); | |
| res.status(202).json(toRuleResponse(rule)); |
|
|
Fix 5 mutation endpoints that were returning HTTP 200 instead of HTTP 202 (Accepted) as declared in the OpenAPI jsonnet specs:
/deploymentversions/{deploymentVersionId}/deployments/{deploymentId}/versions/relationship-rules/{relationshipRuleId}/relationship-rules/{relationshipRuleId}/resources/identifier/{identifier}Closes #1011
Generated with Claude Code