Long-Running Task Notification System
Overview
The Long-Running Task Notification System enables real-time webhook notifications for tasks that run longer than typical request timeouts (minutes, hours, or days). This feature allows clients to receive push notifications about task state changes and artifact generation without maintaining persistent connections or polling. This implementation follows the A2A Protocol specification for push notifications.Table of Contents
- Features
- Architecture
- Quick Start
- Configuration
- Webhook Registration
- Notification Events
- Persistence & Server Restarts
- Global Webhook Fallback
- Security Considerations
- API Reference
- Examples
- Troubleshooting
Features
✅ Persistent Webhook Storage - Webhook configurations survive server restarts✅ Dual Registration Paths - Inline (message/send) or separate RPC endpoint
✅ Global Webhook Fallback - Agent-level default webhook for all tasks
✅ Comprehensive Events - Status updates and artifact notifications
✅ A2A Protocol Compliant - Follows official specification
✅ Secure by Design - Token-based authentication and validation
Architecture
Components
Data Flow
- Task Creation: Client sends task with webhook configuration
- Registration: MessageHandlers registers webhook (persists if long_running=true)
- Execution: ManifestWorker executes task
- Notification: PushNotificationManager sends events to webhook
- Persistence: Webhook config stored in database for long-running tasks
Quick Start
1. Enable Push Notifications in Agent Manifest
2. Send Task with Webhook (Inline Registration)
3. Implement Webhook Receiver
Configuration
Agent Manifest Configuration
Message Send Configuration
Push Notification Configuration
Webhook Registration
Method 1: Inline Registration (Recommended)
Register webhook when creating the task:- ✅ Single API call
- ✅ No race conditions
- ✅ Webhook ready before task starts
Method 2: Separate RPC Registration
Register webhook after task creation:- ✅ Can update webhook mid-task
- ✅ Useful for dynamic workflows
- ⚠️ Two API calls
- ⚠️ Possible race condition for fast tasks
Notification Events
Status Update Event
Sent when task state changes (submitted → working → completed/failed).submitted- Task createdworking- Task executinginput-required- Waiting for user inputauth-required- Waiting for authenticationcompleted- Task finished successfullyfailed- Task failed with errorcanceled- Task canceled by user
Artifact Update Event
Sent when artifacts are generated (currently only on task completion).Persistence & Server Restarts
How It Works
Whenlong_running=true:
- Registration: Webhook config saved to database
- Server Restart: TaskManager loads all persisted configs on startup
- Task Continues: Notifications resume automatically
Database Schema
Example Flow
Global Webhook Fallback
Configuration
Priority Order
- Task-specific webhook (highest priority)
- Global webhook (fallback)
- No webhook (no notifications)
Example
Security Considerations
Server-Side (Sending Notifications)
1. Webhook URL Validation
Risk: SSRF attacks, DDoS amplification Mitigation:2. Authentication to Client Webhook
Current: Bearer token inAuthorization header
Client-Side (Receiving Notifications)
1. Verify Token
2. Prevent Replay Attacks
3. Validate Event Structure
API Reference
MessageSendConfiguration
PushNotificationConfig
RPC Methods
tasks/pushNotification/set
Register or update webhook for a task. Request:tasks/pushNotification/get
Get webhook configuration for a task. Request:tasks/pushNotificationConfig/delete
Delete webhook configuration for a task. Request:Examples
Example 1: Data Processing Pipeline
Example 2: Mobile App with Serverless Webhook
Example 3: Multi-Tenant with Global Webhook
Troubleshooting
Webhook Not Receiving Notifications
Check 1: Push notifications enabled?Webhooks Lost After Server Restart
Problem:long_running flag not set
Solution:
Duplicate Notifications
Problem: Webhook receiver not idempotent Solution: Trackevent_id to deduplicate
Authentication Failures
Problem: Token mismatch Solution: Verify token formatBest Practices
1. Use long_running for Tasks > 30 seconds
2. Implement Webhook Retry Logic
3. Use Global Webhook for Simplicity
4. Monitor Webhook Delivery
5. Secure Webhook URLs
Migration Guide
From Polling to Push Notifications
Before (Polling):Performance Considerations
Webhook Delivery Latency
- Target: < 1 second from event to webhook delivery
- Factors: Network latency, webhook endpoint response time
- Optimization: Use async HTTP client, connection pooling
Database Load
- Webhook configs: Loaded once on startup, cached in memory
- Impact: Minimal - only write on registration, read on startup
- Scaling: Supports 10,000+ concurrent long-running tasks
Memory Usage
- Per webhook config: ~200 bytes (in-memory)
- 10,000 webhooks: ~2 MB memory
- Negligible impact on server resources
References
- A2A Protocol Specification
- Push Notifications for Disconnected Scenarios
- Webhook Security Best Practices
Support
For issues or questions:- GitHub Issues: https://github.com/getbindu/Bindu/issues
- Documentation: https://docs.bindu.ai
Last Updated: December 26, 2025
Version: 1.0.0