Repository navigation
Conversation
…le (a2aproject#1313) A failure in the push-notification infrastructure (config store read or URL validator) propagated into the EventConsumer's generic failure path and rewrote an otherwise successful task as TASK_STATE_FAILED, failing message/send instead of returning the task result. Two non-breaking guards: - BasePushNotificationSender.send_notification: read get_info_for_dispatch inside an error boundary and treat a raising push_url_validator as a rejected URL, both degrading to 'notification not sent' with an exception log. - EventConsumer._update_task_state: wrap the send_notification call in try/except so a sender failure is logged and never disturbs the task state or the event stream. Fixes a2aproject#1313 Signed-off-by: andy <linux2011@qq.com>
🧪 Code Coverage (vs
|
| Base | PR | Delta | |
|---|---|---|---|
| src/a2a/server/agent_execution/active_task.py | 95.02% | 95.05% | 🟢 +0.03% |
| src/a2a/server/cluster/database_event_stream.py | 92.86% | 96.94% | 🟢 +4.08% |
| src/a2a/server/request_handlers/default_request_handler.py | 97.96% | 97.98% | 🟢 +0.02% |
| src/a2a/server/tasks/base_push_notification_sender.py | 94.34% | 95.38% | 🟢 +1.04% |
| Total | 93.10% | 93.15% | 🟢 +0.05% |
Generated by coverage-comment.yml
…re tests Extends the a2aproject#1313 fix to LegacyRequestHandler: its _send_push_notification_if_needed had the same unguarded sender call in both the blocking and streaming paths, so a push-infrastructure failure could fail the task there as well. Also, per self-review: - cover the consumer-level guard in EventConsumer._update_task_state with a raising custom PushNotificationSender (defense-in-depth branch was previously untested); - mirror the codebase's mocked-httpx-client pattern in the v2 e2e tests; - document the fail-closed semantics of the push URL validator and the defense-in-depth role of the consumer guard. Signed-off-by: andy <linux2011@qq.com>
…senders State the guarantee introduced by the a2aproject#1313 guards on the interface and base implementation: implementations may raise, the framework catches and logs, and failures never affect the task lifecycle or the event stream. Signed-off-by: andy <linux2011@qq.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
A failure in the push-notification infrastructure (a transient error while reading
PushNotificationConfigStore, or a raisingpush_url_validator) propagated into the event-consumer's generic failure path and rewrote an otherwise successful task asTASK_STATE_FAILED, failingmessage/sendinstead of returning the task result. Root-cause analysis and a runtime reproduction are in #1313.This adds non-breaking guards so that push delivery stays best-effort, in both handlers:
BasePushNotificationSender.send_notification: theget_info_for_dispatchlookup now runs inside an error boundary, and a raisingpush_url_validatoris treated as a rejected URL (fail closed) — both log vialogger.exceptionand degrade to "notification not sent".DefaultRequestHandlerV2(EventConsumer._update_task_state): thesend_notificationcall is wrapped intry/exceptso a sender failure is logged and never disturbs the task state or the event stream.LegacyRequestHandler._send_push_notification_if_needed: the same unguarded call existed in the legacy handler (both the blocking and streaming paths) — guarded identically.This matches the existing design intent of
_dispatch_notification, which already contains all delivery failures and returnsbool.Notes for reviewers:
Cancellation is unaffected: all guards use
except Exception, andasyncio.CancelledErrorderives fromBaseException, so cancellation still propagates.The best-effort contract is now documented on the
PushNotificationSenderABC andBasePushNotificationSender(custom implementations may raise; the framework logs and continues).Follow the
CONTRIBUTINGGuide.Pull Request title follows the conventional commits specification (
fix:prefix for a SemVer patch).Tests and linter pass.
Appropriate docs were updated (interface/base docstrings now state the best-effort contract).
Fixes #1313 🦕
Testing
tests/server/tasks/test_push_notification_sender.py:push_url_validatorrejects the URL without propagating.tests/server/request_handlers/test_default_request_handler_v2.py:message/sendstill returns theTaskwithTASK_STATE_COMPLETEDand the persisted state is untouched (previously rewritten toFAILED);PushNotificationSender(public interface) is equally harmless — covers the consumer-level guard.tests/server/request_handlers/test_default_request_handler.py:_send_push_notification_if_needed.unused-ignore-commentwarnings pre-exist onmain).