status_check

[alain-sv]

What changed- Added POST /api/supervaizeragents/{agent_slug}/ endpoint (Controller.POST_AGENT_STATUS) and mapped route.

• Endpoint now returns standardized JobResponse model and handler return type updated accordingly.
• Added integration tests that post to the status endpoint and verify job_id, status, message payload are returned and serialized correctly.
• Updated contract to assert the new endpoint is resolved to ensure contract consistency.
• Adjusted from info to debug in case methods to reduce noisy logs during normal.

Why- Expose agent job status via a dedicated, standardized route so clients can reliably obtain job metadata.

• Ensure API contract stability and prevent regressions via tests.
• Reduce noisy logs during normal operation.

Notes- Tests patch Agent.job_status to return JobResponse with EntityStatus to validate mapping and serialization.

[qodo-code-review]

Review Summary by Qodo

Add agent status endpoint with standardized JobResponse model

✨ Enhancement 🧪 Tests

Walkthroughs

Description

• Add POST /api/supervaizer/agents/{agent_slug}/status endpoint returning JobResponse
• Implement standardized job status response with job_id, status, and payload fields
• Add integration test verifying status endpoint returns correct job metadata
• Update controller contract to include new POST_AGENT_STATUS endpoint
• Reduce logging noise by changing case methods from info to debug level

Diagram

flowchart LR
  A["Agent Status Request"] -->|POST /status| B["status_agent Handler"]
  B -->|calls| C["agent.job_status"]
  C -->|returns| D["JobResponse"]
  D -->|serialized| E["Client Response"]
  F["ControllerEndpoint"] -->|maps| G["POST_AGENT_STATUS"]
  G -->|routes to| B

Loading

File Changes

1. src/supervaizer/case.py Logging +2/-2

Reduce logging noise in case methods

• Changed logging level from info to debug in request_human_input method
• Changed logging level from info to debug in request_human_input_sync method
• Reduces noisy logs during normal operation

src/supervaizer/case.py

---

2. src/supervaizer/contracts.py ⚙️ Configuration changes +2/-0

Add POST_AGENT_STATUS to controller contract

• Added POST_AGENT_STATUS enum value to ControllerEndpoint
• Mapped POST_AGENT_STATUS to /api/supervaizer/agents/{agent_slug}/status route
• Ensures API contract consistency for new status endpoint

src/supervaizer/contracts.py

---

3. src/supervaizer/routes.py ✨ Enhancement +9/-10

Update status endpoint to return JobResponse model

• Changed status_agent handler return type from AgentResponse to JobResponse
• Updated response_model decorator to JobResponse
• Updated HTTP 202 response model to JobResponse
• Simplified handler to return agent.job_status() result directly
• Added error handling for null job_status responses with HTTP 404

src/supervaizer/routes.py

---

View more (2)

4. tests/test_contracts.py 🧪 Tests +12/-0

Add contract tests for status endpoint

• Added assertion for POST_AGENT_STATUS endpoint in contract info test
• Added assertion for resolve_controller_endpoint with POST_AGENT_STATUS
• Verifies new endpoint is properly resolved in controller contract

tests/test_contracts.py

---

5. tests/test_routes.py 🧪 Tests +35/-0

Add integration test for status endpoint

• Added imports for JobResponse and EntityStatus
• Added new test test_agent_status_endpoint_returns_job_status_response
• Test mocks Agent.job_status to return JobResponse with job metadata
• Test verifies POST request returns correct job_id, status, and payload fields
• Confirms endpoint serialization and response mapping

tests/test_routes.py

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Misleading 202 status docs ☑ 🐞 Bug ≡ Correctness

Description

The new POST /status route advertises only a 202 Accepted response in its OpenAPI responses, but
the handler returns a normal value with no status_code override (tests assert 200). This mismatch
can break client generation/expectations and makes the contract ambiguous.

Code

src/supervaizer/routes.py[R881-889]

     "/status",
     summary=f"Get the status of the agent: {agent.name}",
     description="Get the status of the agent",
+        response_model=JobResponse,
     responses={
-            http_status.HTTP_202_ACCEPTED: {"model": AgentResponse},
+            http_status.HTTP_202_ACCEPTED: {"model": JobResponse},
     },
     dependencies=[
         Depends(require_scope("write"))

Evidence

The /status decorator declares only HTTP_202_ACCEPTED in responses while the integration test
asserts a 200 response for the same endpoint; additionally, other endpoints that truly mean 202 set
status_code=HTTP_202_ACCEPTED, which /status does not.

src/supervaizer/routes.py[880-887]
tests/test_routes.py[151-181]
src/supervaizer/routes.py[724-736]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`POST /status` documents only a `202 Accepted` response, but the implementation returns a normal `JobResponse` without setting `status_code`, and tests expect `200 OK`. This creates an OpenAPI/behavior mismatch.
### Issue Context
Other endpoints that intend `202` explicitly set `status_code=http_status.HTTP_202_ACCEPTED`.
### Fix Focus Areas
- src/supervaizer/routes.py[880-891]
### Suggested fix
- Decide the intended status code:
- If this is a read-style status fetch, set `status_code=http_status.HTTP_200_OK` and update `responses` to include `HTTP_200_OK` (and optionally `404`).
- If it should be `202`, add `status_code=http_status.HTTP_202_ACCEPTED` and update the test expectation accordingly.
- Update `responses` to reflect actual success + error codes (e.g., 200/404/400).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Sync call blocks event loop ☑ 🐞 Bug ➹ Performance

Description

The async status_agent handler calls agent.job_status(...) synchronously; since
Agent.job_status ultimately runs the underlying method via a direct Python call, the request will
block the FastAPI event loop for the duration of the agent code. This harms concurrency/latency,
especially if clients poll status frequently.

Code

src/supervaizer/routes.py[R893-903]

 async def status_agent(
     params: AgentMethodParams, agent: Agent = Depends(get_agent)
-    ) -> AgentResponse:
+    ) -> JobResponse:
     log.info(f"📥  POST /status [Status agent] {agent.name} with params {params}")
     result = agent.job_status(params.params)
-        return AgentResponse(
-            name=agent.name,
-            id=agent.id,
-            version=agent.version,
-            api_path=agent.path,
-            description=agent.description,
-            **result if result else {},
-        )
+        if result is None:
+            raise HTTPException(
+                status_code=http_status.HTTP_404_NOT_FOUND,
+                detail=f"Agent {agent.name} did not return a job status",
+            )
+        return result

Evidence

status_agent is declared async but calls agent.job_status without await/thread offload.
Agent.job_status delegates to _execute, which imports and invokes the target function via
result = method(**params) synchronously.

src/supervaizer/routes.py[893-903]
src/supervaizer/agent.py[983-988]
src/supervaizer/agent.py[848-862]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`status_agent` is an async route but executes agent code synchronously (via `agent.job_status` -> `_execute` -> `method(**params)`). This blocks the event loop while the agent status function runs.
### Issue Context
Even if many implementations are fast, a single slow `job_status` will stall concurrent requests on the same worker.
### Fix Focus Areas
- src/supervaizer/routes.py[893-903]
- src/supervaizer/agent.py[983-988]
- src/supervaizer/agent.py[848-862]
### Suggested fix
- In `status_agent`, call the sync function in a worker thread:
- `result = await asyncio.to_thread(agent.job_status, params.params)`
- (Optional) Apply the same pattern to other sync agent method endpoints (`/stop`, etc.) if they are expected to do non-trivial work.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Dead None check 🐞 Bug ⚙ Maintainability

Description

status_agent raises a 404 when result is None, but the default Agent._execute enforces that
agent methods return a JobResponse and raises TypeError otherwise, so this None branch is
effectively unreachable under the current implementation. Keeping it can mislead future maintainers
about actual error behavior.

Code

src/supervaizer/routes.py[R896-903]

     log.info(f"📥  POST /status [Status agent] {agent.name} with params {params}")
     result = agent.job_status(params.params)
-        return AgentResponse(
-            name=agent.name,
-            id=agent.id,
-            version=agent.version,
-            api_path=agent.path,
-            description=agent.description,
-            **result if result else {},
-        )
+        if result is None:
+            raise HTTPException(
+                status_code=http_status.HTTP_404_NOT_FOUND,
+                detail=f"Agent {agent.name} did not return a job status",
+            )
+        return result

Evidence

Agent._execute raises if the underlying method does not return a JobResponse, preventing None
from flowing back to the route; therefore if result is None: will not be hit unless
Agent.job_status is bypassed/overridden.

src/supervaizer/routes.py[896-903]
src/supervaizer/agent.py[848-862]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`status_agent` checks `if result is None` and raises 404, but `Agent._execute` already enforces a `JobResponse` return and will raise `TypeError` on `None`/other types.
### Issue Context
This makes the route’s apparent behavior (404 on None) differ from the real behavior (400/500 depending on exception handling).
### Fix Focus Areas
- src/supervaizer/routes.py[896-903]
- src/supervaizer/agent.py[848-862]
### Suggested fix
- Remove the `if result is None:` block, or
- If a 404 is desired for a specific condition (e.g., job_id not found), implement an explicit lookup/validation and raise 404 based on that condition (not on an unreachable `None` return).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---