agentscope-ai / agentscope-ai/agentscope-runtime

[Bug] get_task_status returns 'pending' for both 'submitted' and 'running' states

Abierto
#485 0 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Python
Estrellas
863
Forks
168
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

---
name: Bug Report
about: Create a report to help us improve AgentScope Runtime
title: '[Bug] get_task_status returns "pending" for both "submitted" and "running" states'
labels: 'bug'
assignees: ''
---

**Security Issues: If this involves security vulnerabilities, report via [Alibaba Security Response Center (ASRC)](https://security.alibaba.com/) instead of creating a public issue.**

## Bug Description

The `get_task_status()` method in `task_engine_mixin.py` maps both `submitted` and `running` internal task states to a single `pending` response status. This prevents API consumers (e.g., CLI tools) from distinguishing between a task that is queued vs. one that is actively executing.

## Affected Component
- [x] Engine
- [ ] Sandbox
- [ ] Tools
- [ ] Common
- [ ] Documentation
- [ ] Other:___________

## Reproduction Steps

1. Submit a background task via `POST /agent/process/task` (which internally calls `submit_stream_query_task`)
2. The task is stored in `self.active_tasks` with `status: "submitted"`
3. An async task starts executing via `asyncio.create_task(self.execute_stream_query_task(...))`, which updates the internal status to `"running"`
4. Poll the task status via `GET /agent/process/task/{task_id}` (which calls `get_task_status`)
5. **Bug:** Both states return `{"status": "pending"}`

Relevant code in `agentscope_runtime/engine/deployers/utils/service_utils/routing/task_engine_mixin.py` (memory mode branch, ~line 348-362):

```python
def get_task_status(self, task_id: str):
if self.celery_app:
# Celery branch works correctly (PENDING/SUCCESS/FAILURE)
...
else:
# In-memory mode branch — BUG IS HERE
if task_id not in self.active_tasks:
return {"error": f"Task {task_id} not found"}

task_info = self.active_tasks[task_id]
task_status = task_info.get("status", "unknown")

if task_status in ["submitted", "running"]:
return {"status": "pending", "result": None} # ← Both mapped to "pending"
elif task_status == "completed":
return {"status": "finished", "result": task_info.get("result")}
elif task_status == "failed":
return {"status": "error", "result": task_info.get("error")}
else:
return {"status": task_status, "result": None}
```

Meanwhile, the submit endpoint (`agent_app.py` ~line 568) and the execute method (`execute_stream_query_task` ~line 288) correctly set the internal status to `"submitted"` and `"running"` respectively:

```python
# agent_app.py — submit
self.active_tasks[task_id] = {
"status": "submitted", # Correctly set
...
}

# task_engine_mixin.py — execute_stream_query_task
self.active_tasks[task_id].update({
"status": "running", # Correctly set
...
})
```

The internal state machine works correctly; the bug is only in the `get_task_status()` response mapping.

## Expected vs Actual Behavior

**Expected:** API should return distinct statuses matching the internal state:
- `submitted` → `{"status": "submitted"}`
- `running` → `{"status": "running"}`
- `completed` → `{"status": "finished"}`
- `failed` → `{"status": "error"}`

This would allow consumers (CLI, UI, orchestrators) to show appropriate progress indicators like "Task submitted, waiting to start..." vs. "Task is running...".

**Actual:** Both `submitted` and `running` are collapsed into `pending`, so consumers cannot tell if a task is queued or actively executing.

## Error Messages

No error — the API returns a valid response, but with incorrect state information. The CLI displays:

```
[TASK_ID: dc554d72-bf5b-416c-bc75-b6e077b10355]
[STATUS: pending]

⏸️ Task is pending in queue...
```

Even when the task has been actively running for several minutes (confirmed by session logs showing 68 rounds of tool calls executing).

## Environment

- **AgentScope Runtime Version:** 1.1.3
- **Python Version:** 3.13.12
- **OS:** Linux 6.14.0-37-generic (x86_64)
- **Installation:** pip (via qwenpaw dependency)
- **Run Mode:** In-memory (non-Celery)

## Additional Context

**Real-world impact:** This bug caused an orchestration failure in a multi-agent system. The calling agent (`default`) submitted a background task to a worker agent (`spec-runner`). Because `get_task_status` always returned `pending`, the caller assumed the worker was not executing the task and proceeded to execute it independently — violating the delegation contract.

**Suggested fix:** In `task_engine_mixin.py`, change the in-memory branch of `get_task_status`:

```python
if task_status == "submitted":
return {"status": "submitted", "result": None}
elif task_status == "running":
return {"status": "running", "result": None}
elif task_status == "completed":
return {"status": "finished", "result": task_info.get("result")}
elif task_status == "failed":
return {"status": "error", "result": task_info.get("error", "Unknown error")}
else:
return {"status": task_status, "result": None}
```

**Evidence:** Task session file at `/home/codeasier/.copaw/workspaces/spec-runner/sessions/default--to--spec-runner--1776164674678--4599535c_*.json` (150KB, 68 messages) confirms the task was actively executing for ~5 minutes while the API continuously returned `pending`.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.