[Linux2010]

Description

Framework failure paths could persist a FAILED task without status.timestamp, and DatabaseTaskStore derives last_updated from status.timestamp (database_task_store.py:152-156) — so the task was persisted with last_updated = NULL, breaking ListTasks ordering and status_timestamp_after filtering. Root-cause analysis and a runtime reproduction are in #1331.

Per the two-layer approach endorsed on the issue:

• Failure sites stamp explicitly (ActiveTask): _write_failed_status, _mark_task_as_failed, and the producer failure path now stamp the current time on the FAILED status.
• Defensive backstop in TaskManager.save_task_event: a terminal state arriving without a timestamp (raw Task path or status-event path) is auto-stamped with the current time, so future call sites cannot reintroduce the NULL-last_updated hole.

Semantics: non-terminal states are never touched, and explicitly provided timestamps are never overwritten.

• Follow the CONTRIBUTING Guide
• PR title follows Conventional Commits (fix: → SemVer patch)
• Tests and linter pass
• Appropriate docs were updated (guard docstring states the contract)

Fixes #1331 🦕

Validation

• Claim: an executor crashing mid-flight now persists TASK_STATE_FAILED with status.timestamp set; non-terminal statuses and explicitly provided timestamps are untouched.
• Exact head: c34c53f
• BEFORE: persisted task = state=TASK_STATE_FAILED, timestamp set=False (repro in [Bug]: Framework-written FAILED status drops status.timestamp, persisting last_updated as NULL #1331). AFTER: timestamp set=True.
• Tests: 4 new tests in tests/server/tasks/test_task_manager.py (terminal-unstamped auto-stamp, provided-timestamp preserved, non-terminal untouched, raw-Task path guarded) + 1 end-to-end in test_default_request_handler_v2.py.
• Full suite: 2302 passed, coverage 93% (gate 88%).
• Environment: Python 3.10.20, macOS.
• Limits / not tested: DatabaseTaskStore integration (covered indirectly via the same status pipeline; the e2e asserts the in-memory store the same way CI's coverage report measures it).

Prepared with AI assistance (WorkBuddy); reviewed and verified by Linux2010

[github-actions]

🧪 Code Coverage (vs main)

⬇️ Download Full Report

	Base	PR	Delta
src/a2a/server/agent_execution/active_task.py	95.40%	95.45%	🟢 +0.05%
src/a2a/server/cluster/database_event_stream.py	92.86%	96.94%	🟢 +4.08%
src/a2a/server/tasks/task_manager.py	98.86%	98.92%	🟢 +0.06%
Total	92.89%	92.95%	🟢 +0.05%

Generated by coverage-comment.yml

[Linux2010]

Friendly ping — this is ready for review whenever anyone has bandwidth (both branches just rebased onto latest main). Happy to address any feedback. Thanks!

[mykytanetipa]

Why only stamp terminal states in TaskManager?

• If an agent sends an unstamped WORKING or INPUT_REQUIRED update (for example via new_text_status_update_event, which doesn't set a timestamp), task.status.CopyFrom(event.status) still wipes out the existing timestamp and writes last_updated = NULL to the DB.

• New SUBMITTED tasks created via new_task_from_user_message or TaskManager._init_task_obj (which ensure_task_id saves directly through _save_task) also start without a timestamp, so tasks created with return_immediately=True or artifact-first flows end up with last_updated = NULL too.

I think we should stamp any status that lacks a timestamp (in save_task_event and _init_task_obj / _save_task), not just terminal ones

[mykytanetipa]

This needs a rebase onto main. #1366 already removed the failure write in _run_producer and updated _write_failed_status to set status.timestamp.FromDatetime(datetime.now(timezone.utc)) directly.

After rebasing, only _mark_task_as_failed (and cancel, see below) will need stamping here, and we can just call .FromDatetime(datetime.now(timezone.utc)) directly instead of adding _now_timestamp().

[mykytanetipa]

We are still missing timestamps on the CANCELED paths:

• In ActiveTask.cancel(), updated.CopyFrom(task) copies the old timestamp from the previous state (like WORKING or INPUT_REQUIRED) and only changes state to CANCELED. Since timestamp is already set on the copy, _stamp_terminal_timestamp in TaskManager won't update it, so the task keeps the stale timestamp.

• In DefaultRequestHandlerV2._write_cancel(), we call _versioned_store.save() directly without going through TaskManager, so cancelled.status.timestamp is either left empty or keeps the old timestamp.

Both places should explicitly set status.timestamp.FromDatetime(datetime.now(timezone.utc)) when transitioning to CANCELED.

[mykytanetipa]

If we stamp task after task.status.CopyFrom(event.status), event.status.timestamp stays empty. That same event object is then sent to streaming subscribers, push notifications, and the task_events table without a timestamp. If we stamp event.status before CopyFrom, both the event and the task get the same timestamp.