Skip to content

blocking on_message_send treats a FAILED Task as a successful result #1228

Description

@anthonyrs06

Summary

Follow-up from @astrogilda's review of #1191 / #1175.

Blocking DefaultRequestHandlerV2.on_message_send returns successfully when it sees a Task in any terminal state, including FAILED:

            if isinstance(event, Task) and (
                params.configuration.return_immediately
                or event.status.state
                in (TERMINAL_TASK_STATES | INTERRUPTED_TASK_STATES)
            ):
                self._validate_task_id_match(task_id, event.id)
                result = event
                break

A producer crash that also emits TaskStatusUpdateEvent(FAILED) (with replace_status_update_with_task=True) therefore becomes a successful blocking message/send instead of an A2AClientError. Scenarios 9 and 12 encode the current contract: the producer exception must surface.

That is why #1191 persists FAILED + push on producer-failure but does not enqueue a FAILED status event on the subscriber stream. After #1191, a streaming client that survives the exception still cannot distinguish "the producer crashed" from "the connection dropped" without a get_task() poll.

Proposal

Treat a FAILED terminal Task as an error on the blocking path (or keep reading until the producer exception arrives), so a FAILED status event can be published to live streams without converting a crash into success. Until then, #1175's producer-failure half stays polling-dependent.

Related

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

component: serverIssues related to frameworks for agent execution, HTTP/event handling, database persistence logic.

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions