Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 459d282e78
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| schemes: | ||
| - ws | ||
| - wss | ||
| type: object |
There was a problem hiding this comment.
GET /options is documented with schema: { type: object }, but the handler returns a slice from helpers.Store(r).GetOptions(...) and writes it directly (api/options.go), so the payload is an array of options. Generated clients using this spec will deserialize into the wrong shape and fail or drop data when calling this endpoint.
Useful? React with 👍 / 👎.
| 200: | ||
| description: Integration received |
There was a problem hiding this comment.
The webhook endpoint documents successful GET/POST /integrations/{integration_alias} responses as 200, but ReceiveIntegration ends with w.WriteHeader(http.StatusNoContent) (api/integration.go), i.e. 204 on success. Clients generated from this spec may treat valid 204 responses as undocumented/unexpected and surface false failures.
Useful? React with 👍 / 👎.
| 204: | ||
| description: Valid cron format |
There was a problem hiding this comment.
The new /project/{project_id}/schedules/validate docs list success as 204, but ValidateScheduleCronFormat returns without writing a status when validation passes (api/projects/schedules.go), so net/http sends 200 OK. Keeping 204 here makes the spec disagree with runtime behavior and can break strict status-code handling in API clients.
Useful? React with 👍 / 👎.
1 participant
No description provided.