conductor-oss / conductor-oss/python-sdk

Framework-agent failures return `None` instead of the failed task's reason

Ouverte Adaptée aux débutants
#483 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
bug
Langage dominant
Python
Étoiles
104
Forks
42
Merge moyen
2 j 1 h
PR mergées (30 j)
3

Description

**In short:** when a framework agent fails, the SDK prints `None` instead of the reason — even though the server recorded a perfectly good one. Every such failure costs a manual walk of the server API to diagnose.

**File:** `src/conductor/ai/agents/runtime/runtime.py`

## Symptom

```
$ CONDUCTOR_AGENT_LLM_MODEL=anthropic/claude-sonnet-4-6 python examples/agents/93_openai_runner_hello_world.py
Framework agent 'Assistant' execution FAILED
None
```

No reason, no task name, nothing actionable. Diagnosing it means walking the server API by hand:

```
curl -s localhost:8080/api/agent/executions?size=20
curl -s "localhost:8080/api/workflow/?includeTasks=true" # find FAILED tasks, read reasonForIncompletion
```

## Cause

`_run_framework()` reports:

```python
error=status.reason if raw_status in ("FAILED", "TERMINATED") else None
```

For these failures `status.reason` is empty, so the result is `None`.

The reason was available all along, at both levels of the execution:

- the **workflow's** own `reasonForIncompletion`:
```
Task 41830611-7c25-4d51-a36f-50e324e59239 failed with status: FAILED and reason:
'Task execution failed: OpenAI Responses API call failed: Responses API failed with status 401 ...'
```
- the failed **task's** `reasonForIncompletion` (`Assistant_llm`), carrying the same text.

There is also an existing helper that already does this. `_extract_failed_task_reason(wf)` reads the first FAILED task's `reasonForIncompletion` and returns `Task '' failed: `. It is called by `run()` (line ~2534) and `_run_by_name()` (line ~2623) — which is why **native**-agent failures report properly, e.g. `54_software_bug_assistant` prints:

```
ERROR: Task 'software_assistant_54_list_mcp_0' failed: Failed to list MCP tools ... HTTP 400
```

`_run_framework()` never calls it.

## Fix

When `status.reason` is empty, fall back to the workflow's `reasonForIncompletion`, or call `_extract_failed_task_reason` as `run()` does. Either is sufficient.

## Verify

Start the server without `OPENAI_API_KEY`, run `93` — it should name the failing task and its reason instead of printing `None`.

## Note — possible second gap, unconfirmed

`59_coding_agent` goes through `run()` yet also reported no reason, while its server-side SUB_WORKFLOW task did carry one (`Anthropic Messages API failed with status 404`). `_extract_failed_task_reason` only inspects the top-level workflow's tasks, so failures inside a sub-workflow may need the same treatment. Worth checking while fixing this.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Piste de recherche

Start in src/conductor/ai/agents/runtime/runtime.py at _run_framework(), then compare its failure reporting with _extract_failed_task_reason and the calls from run() and _run_by_name(). Run examples/agents/93_openai_runner_hello_world.py with the server lacking OPENAI_API_KEY; done means the framework-agent failure names the failed task and reports its reason instead of None.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
python
Domaine
backend
Type d'issue
Bug
Difficulté
2/5
Temps estimé
1-3 heures
Activité
Calme
Clarté
Clairement spécifiée
Accessibilité débutants
78/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.