fix(httpapi): restore handler package build#471
Conversation
Remove stale duplicate handler methods from server.go so handlers.go is the single implementation surface, restore the missing version response model, and repair malformed HTTP API tests. Validation: - go test ./lib/httpapi - go test ./internal/harness ./internal/routing ./internal/server ./lib/screentracker ./x/acpio ./test ./lib/httpapi - go test ./... Co-authored-by: Codex <noreply@openai.com>
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
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 57 minutes and 42 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: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ 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 |
|
| } | ||
| } | ||
|
|
||
| // Start starts the HTTP server |
There was a problem hiding this comment.
🟠 Architect Review — HIGH
The active /status handler in handlers.go no longer sets StatusResponse.Body.Transport, so the /status JSON always has an empty transport field even when the server is running with ACP transport. The attach CLI relies on this field (via cmd/attach/checkACPMode) to detect ACP servers; with the field unset, ACP servers are misclassified as PTY and attach proceeds against an unsupported transport.
Suggestion: Keep handlers.go as the single implementation surface, but update getStatus to populate StatusResponse.Body.Transport from the server's configured transport (e.g., s.transport). Add/restore a test that hits /status for both PTY and ACP configurations and asserts that the transport field is present and correct so clients like cmd/attach can reliably detect ACP mode.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is an **Architect / Logical Review** comment left during a code review. These reviews are first-class, important findings — not optional suggestions. Do NOT dismiss this as a 'big architectural change' just because the title says architect review; most of these can be resolved with a small, localized fix once the intent is understood.
**Path:** lib/httpapi/server.go
**Line:** 343:350
**Comment:**
*HIGH: The active /status handler in handlers.go no longer sets StatusResponse.Body.Transport, so the /status JSON always has an empty transport field even when the server is running with ACP transport. The attach CLI relies on this field (via cmd/attach/checkACPMode) to detect ACP servers; with the field unset, ACP servers are misclassified as PTY and attach proceeds against an unsupported transport.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
If a suggested approach is provided above, use it as the authoritative instruction. If no explicit code suggestion is given, you MUST still draft and apply your own minimal, localized fix — do not punt back with 'no suggestion provided, review manually'. Keep the change as small as possible: add a guard clause, gate on a loading state, reorder an await, wrap in a conditional, etc. Do not refactor surrounding code or expand scope beyond the finding.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fixThere was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is ON, but it could not run because the branch was deleted or merged before autofix could start.
Reviewed by Cursor Bugbot for commit 7652f7e. Configure here.
| type InfoResponse struct { | ||
| Body struct { | ||
| Version string `json:"version" doc:"AgentAPI version"` | ||
| AgentType mf.AgentType `json:"agent_type" doc:"Type of the agent being used by the server."` |
There was a problem hiding this comment.
Transport field never set in status handler
High Severity
The removed getStatus in server.go set resp.Body.Transport = s.transport, but the surviving implementation in handlers.go omits this assignment. Since StatusResponse still declares a Transport field, the /status endpoint now always returns an empty string for transport instead of the actual value ("pty" or "acp"). Clients relying on this field to determine the backend transport will break.
Reviewed by Cursor Bugbot for commit 7652f7e. Configure here.
| if !json.Valid(w.Body.Bytes()) { | ||
| t.Fatalf("expected valid OpenAPI JSON, got %q", w.Body.String()) | ||
| } |
There was a problem hiding this comment.
Suggestion: This assertion only checks that /openapi.json is syntactically valid JSON, but no longer verifies it matches the checked-in schema file, so OpenAPI drift will pass unnoticed. Restore a deterministic comparison against the on-disk openapi.json content (after normalization if needed). [logic error]
Severity Level: Critical 🚨
- ❌ API contract drift between `/openapi.json` endpoint and openapi.json file.
- ⚠️ Generated SDKs using openapi.json may misrepresent server behavior.Steps of Reproduction ✅
1. Open `lib/httpapi/server_test.go:25-27` and note the comment on `TestOpenAPISchema`
stating it should "Ensure the OpenAPI schema on disk is up to date" and referencing
`openapi.json`.
2. Inspect `TestOpenAPISchema` implementation at `lib/httpapi/server_test.go:28-54`: lines
31-39 construct a server via `NewServer`, lines 42-47 issue a `GET /openapi.json` request
using `httptest`, and lines 48-53 only assert that `w.Code == http.StatusOK` and
`json.Valid(w.Body.Bytes())`, without reading or comparing against the checked-in
`openapi.json` file.
3. Confirm via repository search that no Go code compares the HTTP response to the on-disk
schema: `grep -R "openapi.json" -n` shows usages in comments and scripts such as
`version.sh:12` and `scripts/validate_openapi_agent_client_module.sh:29-36`, but no test
in `lib/httpapi` opens or parses `openapi.json`, so `TestOpenAPISchema` cannot detect
discrepancies by design.
4. In this state, a developer can change the server routes or regenerate `/openapi.json`
output without updating the committed `openapi.json` (or vice versa); as long as the
endpoint response remains syntactically valid JSON, `go test ./lib/httpapi -run
TestOpenAPISchema` will still pass, allowing drift between the runtime `/openapi.json`
(produced by `Server.GetOpenAPI` in `lib/httpapi/server.go:73-91`) and the stored
`openapi.json` contract used by tooling in `version.sh` and
`scripts/validate_openapi_agent_client_module.sh`.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** lib/httpapi/server_test.go
**Line:** 51:53
**Comment:**
*Logic Error: This assertion only checks that `/openapi.json` is syntactically valid JSON, but no longer verifies it matches the checked-in schema file, so OpenAPI drift will pass unnoticed. Restore a deterministic comparison against the on-disk `openapi.json` content (after normalization if needed).
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| t.Parallel() | ||
| ctx := logctx.WithLogger(context.Background(), slog.New(slog.NewTextHandler(os.Stdout, nil))) | ||
| srv, err := httpapi.NewServer(ctx, httpapi.ServerConfig{ | ||
| srv, err := NewServer(ctx, ServerConfig{ |
There was a problem hiding this comment.
Suggestion: NewServer allocates a temporary upload directory that is only removed by Server.Stop, but this test never calls Stop, so each run leaks directories on disk. Add a cleanup hook right after construction to call srv.Stop(...) (or equivalent) so resources are released even when assertions fail. [resource leak]
Severity Level: Major ⚠️
- ⚠️ `go test ./lib/httpapi` leaves temp upload directories.
- ⚠️ Repeated CI runs accumulate `agentapi-uploads-*` under os.TempDir.Steps of Reproduction ✅
1. Inspect the server's temporary upload directory creation in `lib/httpapi/server.go`:
lines 200-205 call `os.MkdirTemp("", "agentapi-uploads-")` and store the path in
`Server.tempDir`, and lines 355-372 define `Server.Stop` which calls `cleanupTempDir()` to
remove that directory.
2. Open `lib/httpapi/server_test.go` and locate `TestServer_UploadFiles` at lines 772-925;
lines 772-783 create `srv, err := NewServer(ctx, ServerConfig{...})` without any
corresponding call to `srv.Stop` or other cleanup for `srv.tempDir`.
3. Before running tests, list the OS temp directory (e.g. `ls "$(go env GOTMPDIR)"`) and
note there are no `agentapi-uploads-*` entries; then run `go test ./lib/httpapi -run
TestServer_UploadFiles` to execute the upload tests that construct `NewServer` without
stopping it.
4. After the test run, list the same temp directory again and observe a new
`agentapi-uploads-*` directory remains, confirming that `NewServer` allocations from
`server.go:201` are not cleaned up because `Server.Stop` (which performs `cleanupTempDir`
at `server.go:360-372`) is never invoked from `TestServer_UploadFiles` in
`lib/httpapi/server_test.go:772-783`.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** lib/httpapi/server_test.go
**Line:** 775:783
**Comment:**
*Resource Leak: `NewServer` allocates a temporary upload directory that is only removed by `Server.Stop`, but this test never calls `Stop`, so each run leaks directories on disk. Add a cleanup hook right after construction to call `srv.Stop(...)` (or equivalent) so resources are released even when assertions fail.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
CodeAnt AI finished reviewing your PR. |
|
CodeAnt AI is running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Sequence DiagramThis PR restores the typed version response model and ensures the HTTP API exposes a valid OpenAPI JSON document via the unified handler implementation. sequenceDiagram
participant Client
participant HTTP API server
participant Version module
Client->>HTTP API server: GET /version
HTTP API server->>Version module: Read current version
Version module-->>HTTP API server: Version string
HTTP API server-->>Client: 200 OK (VersionResponse)
Client->>HTTP API server: GET /openapi.json
HTTP API server->>HTTP API server: Generate OpenAPI JSON
HTTP API server-->>Client: 200 OK (OpenAPI schema)
Generated by CodeAnt AI |
| srv, err := NewServer(ctx, ServerConfig{ | ||
| AgentType: msgfmt.AgentTypeClaude, | ||
| AgentIO: nil, | ||
| Port: 0, | ||
| ChatBasePath: "/chat", | ||
| AllowedHosts: []string{"*"}, | ||
| AllowedOrigins: []string{"*"}, | ||
| }) | ||
| require.NoError(t, err) |
There was a problem hiding this comment.
Suggestion: NewServer allocates a temporary upload directory, but this test never calls srv.Stop(), so the cleanup path (cleanupTempDir) is skipped and temp directories accumulate across test runs. Add a t.Cleanup that calls srv.Stop(...) (with a bounded context) after successful server creation. [resource leak]
Severity Level: Major ⚠️
- ⚠️ lib/httpapi tests leave temp upload directories on disk.
- ⚠️ Repeated test runs accumulate agentapi-uploads-* directories under /tmp.
- ⚠️ Slight risk of disk bloat on CI hosts.Steps of Reproduction ✅
1. Run `go test ./lib/httpapi`, which executes tests that call `NewServer`, including
`TestOpenAPISchema` at `lib/httpapi/server_test.go:28-54`,
`TestServer_SSEMiddleware_Events` at `lib/httpapi/server_test.go:725-760`,
`TestServer_UploadFiles` at `lib/httpapi/server_test.go:772-925`, and
`TestServer_UploadFiles_Errors` at `lib/httpapi/server_test.go:927-1070`.
2. In each of these tests, a server is constructed via `srv, err := NewServer(ctx,
ServerConfig{...})` (for example at `lib/httpapi/server_test.go:32-39` and
`lib/httpapi/server_test.go:775-782`), with `require.NoError(t, err)` immediately after,
but there is no subsequent call to `srv.Stop(...)` in those tests.
3. The `NewServer` implementation in `lib/httpapi/server.go:112-240` unconditionally
creates a temporary upload directory using `os.MkdirTemp("", "agentapi-uploads-")` at
lines `200-205`, stores the path in `Server.tempDir`, and logs `"Created temporary
directory for uploads"`.
4. The only place that cleans up this directory is `Server.Stop` in
`lib/httpapi/server.go:354-370`, which calls `s.cleanupTempDir()` at
`lib/httpapi/server.go:360-378`; since the tests never invoke `srv.Stop`, the
`agentapi-uploads-*` directories remain on disk. Re-running `go test ./lib/httpapi`
multiple times and inspecting the system temp directory (e.g. `/tmp`) shows an
accumulating set of `agentapi-uploads-*` directories created by these tests without
cleanup.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** lib/httpapi/server_test.go
**Line:** 32:40
**Comment:**
*Resource Leak: `NewServer` allocates a temporary upload directory, but this test never calls `srv.Stop()`, so the cleanup path (`cleanupTempDir`) is skipped and temp directories accumulate across test runs. Add a `t.Cleanup` that calls `srv.Stop(...)` (with a bounded context) after successful server creation.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
CodeAnt AI finished running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
CodeAnt AI is running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Sequence DiagramThis diagram shows how the HTTP API server now exposes the restored version endpoint and routes conversation, upload, and event stream requests through a single handler implementation, as consolidated in this PR. sequenceDiagram
participant Client
participant HTTPAPI
participant Conversation
participant EventEmitter
Client->>HTTPAPI: GET /version
HTTPAPI-->>Client: 200 OK with VersionResponse
Client->>HTTPAPI: Conversation or upload request
HTTPAPI->>Conversation: Handle status, messages, and uploads via shared handlers
HTTPAPI-->>Client: 200 OK with response data
Client->>HTTPAPI: GET /events
HTTPAPI->>EventEmitter: Subscribe client to conversation events
EventEmitter-->>Client: Stream events over SSE
Generated by CodeAnt AI |
| ctx := logctx.WithLogger(context.Background(), slog.New(slog.NewTextHandler(os.Stdout, nil))) | ||
|
|
||
| srv, err := httpapi.NewServer(ctx, httpapi.ServerConfig{ | ||
| srv, err := NewServer(ctx, ServerConfig{ |
There was a problem hiding this comment.
Suggestion: NewServer allocates a temp upload directory that is only removed by Server.Stop, but these new tests instantiate servers without registering a cleanup call to stop them. This leaks temporary directories across the test suite and can eventually cause resource exhaustion/flaky CI runs. Add a t.Cleanup that calls srv.Stop(...) (or a helper that always stops test servers) immediately after each successful NewServer call. [resource leak]
Severity Level: Major ⚠️
- ⚠️ `go test ./lib/httpapi` leaves temp upload directories behind.
- ⚠️ Repeated CI runs can clutter or exhaust `/tmp` storage.Steps of Reproduction ✅
1. Run `go test ./lib/httpapi` so that all tests in `lib/httpapi/server_test.go` execute,
including `TestOpenAPISchema` (lines 28-54), `TestServer_SSEMiddleware_Events` (lines
326-361), `TestServer_UploadFiles` (lines 373-526), `TestServer_UploadFiles_Errors` (lines
528-671), and `TestServer_Stop_Idempotency` (lines 673-703).
2. Each of these tests constructs a server via `NewServer` (e.g. `srv, err :=
NewServer(ctx, ServerConfig{...})` at `lib/httpapi/server_test.go:32`, `:329`, `:376`,
`:531`, and `:677`, including the snippet at diff lines 1076–1083), creating a `*Server`
instance per test case.
3. Inside `NewServer` (`lib/httpapi/server.go:112-239`), the implementation always creates
a per-server temporary upload directory with `tempDir, err := os.MkdirTemp("",
"agentapi-uploads-")` and stores it in `Server.tempDir` (lines 200-205), and later relies
on `Server.Stop` to call `cleanupTempDir()` (lines 355-372) to remove that directory.
4. Aside from `TestServer_Stop_Idempotency`, none of these tests ever invoke
`srv.Stop(...)` (verified by `rg "Stop(" lib/httpapi/server_test.go` only matching the
stop-idempotency test at lines 1089-1101), so after `go test ./lib/httpapi` completes you
can inspect the system temp directory (e.g. `/tmp/agentapi-uploads-*`) and observe
multiple leftover test-created directories that were never cleaned up, confirming the
resource leak across the test suite.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** lib/httpapi/server_test.go
**Line:** 1076:1083
**Comment:**
*Resource Leak: `NewServer` allocates a temp upload directory that is only removed by `Server.Stop`, but these new tests instantiate servers without registering a cleanup call to stop them. This leaks temporary directories across the test suite and can eventually cause resource exhaustion/flaky CI runs. Add a `t.Cleanup` that calls `srv.Stop(...)` (or a helper that always stops test servers) immediately after each successful `NewServer` call.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| } | ||
| } | ||
|
|
||
| // Start starts the HTTP server |
There was a problem hiding this comment.
🔴 Architect Review — CRITICAL
Removing the in-file handler implementations in server.go left the active getStatus handler in handlers.go without setting StatusResponse.Body.Transport, so /status returns an empty transport and cmd/attach can no longer reliably detect ACP mode before attempting unsupported attach flows.
Suggestion: In getStatus, populate StatusResponse.Body.Transport from the server's configured transport (s.transport) and add an HTTP API test that asserts /status includes a valid non-empty transport value (pty or acp).
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is an **Architect / Logical Review** comment left during a code review. These reviews are first-class, important findings — not optional suggestions. Do NOT dismiss this as a 'big architectural change' just because the title says architect review; most of these can be resolved with a small, localized fix once the intent is understood.
**Path:** lib/httpapi/server.go
**Line:** 343:350
**Comment:**
*CRITICAL: Removing the in-file handler implementations in server.go left the active getStatus handler in handlers.go without setting StatusResponse.Body.Transport, so /status returns an empty transport and cmd/attach can no longer reliably detect ACP mode before attempting unsupported attach flows.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
If a suggested approach is provided above, use it as the authoritative instruction. If no explicit code suggestion is given, you MUST still draft and apply your own minimal, localized fix — do not punt back with 'no suggestion provided, review manually'. Keep the change as small as possible: add a guard clause, gate on a loading state, reorder an await, wrap in a conditional, etc. Do not refactor surrounding code or expand scope beyond the finding.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
CodeAnt AI finished running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
CodeAnt AI is running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Sequence DiagramThis PR restores the version response model and aligns the HTTP API and tests so that version details and the generated OpenAPI schema are both served correctly through the unified handler layer. sequenceDiagram
participant Client
participant APIServer
participant VersionModule
Client->>APIServer: GET /version
APIServer->>VersionModule: Read current version
VersionModule-->>APIServer: Version string
APIServer-->>Client: 200 OK (version response)
Client->>APIServer: GET /openapi.json
APIServer->>APIServer: Apply host rules and generate schema
APIServer-->>Client: 200 OK (OpenAPI JSON)
Generated by CodeAnt AI |
| t.Parallel() | ||
| ctx := logctx.WithLogger(context.Background(), slog.New(slog.NewTextHandler(os.Stdout, nil))) | ||
| s, err := httpapi.NewServer(ctx, httpapi.ServerConfig{ | ||
| s, err := NewServer(ctx, ServerConfig{ |
There was a problem hiding this comment.
Suggestion: In TestServer_CORSOrigins, the constructor error from NewServer is not asserted on non-validation-error paths before s.Handler() is used. If server construction fails unexpectedly, this can dereference a nil server and panic the test instead of reporting a clear assertion failure. Add an explicit require.NoError(t, err) before using s. [null pointer]
Severity Level: Major ⚠️
- ⚠️ CORS origins tests may panic on constructor failure.
- ⚠️ Panic obscures underlying configuration or validation error details.Steps of Reproduction ✅
1. Execute `go test ./lib/httpapi` so `TestServer_CORSOrigins` in
`lib/httpapi/server_test.go:484-640` runs its table-driven cases.
2. For each case, the test constructs a server via `s, err := NewServer(ctx,
ServerConfig{... AllowedOrigins: tc.allowedOrigins, })` at
`lib/httpapi/server_test.go:597-604`, which calls `NewServer` in
`lib/httpapi/server.go:111-239`.
3. `NewServer` parses allowed origins via `parseAllowedOrigins` at
`lib/httpapi/server.go:125-128`; if parsing or validation fails for a configuration that
the test marks as valid (where `tc.validationErrorMsg == ""` at
`lib/httpapi/server_test.go:492-543`), it returns `nil, error`.
4. In the `tc.validationErrorMsg == ""` branch, the test does not assert
`require.NoError(t, err)` before calling `s.Handler()` at
`lib/httpapi/server_test.go:610`, so if `err` is non-nil, `s` is nil and `s.Handler()`
dereferences a nil receiver, panicking the test instead of reporting a clear assertion
failure about server construction.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** lib/httpapi/server_test.go
**Line:** 597:604
**Comment:**
*Null Pointer: In `TestServer_CORSOrigins`, the constructor error from `NewServer` is not asserted on non-validation-error paths before `s.Handler()` is used. If server construction fails unexpectedly, this can dereference a nil server and panic the test instead of reporting a clear assertion failure. Add an explicit `require.NoError(t, err)` before using `s`.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
CodeAnt AI finished running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
CodeAnt AI is running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Sequence DiagramThis PR restores the VersionResponse model and relies on the unified handler layer so the HTTP API server can serve a valid OpenAPI schema at /openapi.json and a structured version payload at /version. sequenceDiagram
participant Client
participant HTTPAPIServer
participant OpenAPIEngine
participant VersionModule
Client->>HTTPAPIServer: GET /openapi.json
HTTPAPIServer->>OpenAPIEngine: Generate OpenAPI schema from routes and models
OpenAPIEngine-->>HTTPAPIServer: OpenAPI JSON
HTTPAPIServer-->>Client: 200 OK with OpenAPI JSON
Client->>HTTPAPIServer: GET /version
HTTPAPIServer->>VersionModule: Read current server version
VersionModule-->>HTTPAPIServer: Version string
HTTPAPIServer-->>Client: 200 OK with VersionResponse JSON
Generated by CodeAnt AI |
|
CodeAnt AI finished running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |




User description
Summary
server.gosohandlers.gois the single implementation surfaceVersionResponsemodelValidation
go test ./lib/httpapigo test ./internal/harness ./internal/routing ./internal/server ./lib/screentracker ./x/acpio ./test ./lib/httpapigo test ./...Note
Low Risk
Low risk: this primarily removes duplicate handler implementations and fixes/strengthens tests, with minimal functional change beyond re-adding a missing response model.
Overview
Fixes
lib/httpapibuild issues by removing stale duplicate HTTP handler methods fromserver.go, makinghandlers.gothe single source of truth for request handling.Restores the missing
VersionResponsemodel and updates HTTP API tests to use the package-localNewServer/ServerConfig, validate/openapi.jsonreturns valid JSON, and correct a malformed allowed-hosts test.Reviewed by Cursor Bugbot for commit 7652f7e. Bugbot is set up for automated code reviews on this repo. Configure here.
CodeAnt-AI Description
Restore the HTTP API build and version response
What Changed
/openapi.jsonreturns valid JSONImpact
✅ Restored version info in API responses✅ Fewer HTTP API build failures✅ Clearer OpenAPI checks🔄 Retrigger CodeAnt AI Review
Details
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.