Notify an idle device when work arrives
A polling Connector has to ask for work even when there is none. Frequent polling shortens the delay before a tool starts, but creates idle traffic and repeated server work. This update replaces reliance on one-second idle polling with an authenticated outbound WebSocket that can wake the device when a task is available.
For example, an agent submits a read while the connected device is idle. The service stores the invocation, then emits dispatch.available. The Connector receives the signal and polls promptly rather than waiting for the next scheduled idle check. This changes discovery latency, not the file tool or the authorization contract.
The wake signal carries no invocation body, path, credential or authorization decision. The Connector still uses the signed poll endpoint. The service revalidates policy, and PostgreSQL atomically claims the dispatch. A wake signal alone never authorizes execution.
Recover missed signals from stored tasks
Wake delivery is best effort. A proxy can restart, a laptop can sleep, or a message can be lost. Reconnection triggers an immediate poll; a 30-second fallback poll recovers available work even when no wake arrives. The stored task remains authoritative, so a missed signal does not delete it and repeated signals do not create extra invocations.
The device uses reconnect backoff with jitter. In a single control-plane instance it keeps one active wake connection per device. A slower fallback is a recovery mechanism, not a promise that every task starts within 30 seconds: offline devices, approvals, queueing and expired budgets can still prevent execution.
This is a transport change for task notifications. It does not introduce a peer-to-peer tool path or a general tunnel. Results and task reads continue through the existing service, and side-effect recovery still depends on the original task identity and receipt.
Check connection, polling and task evidence together
Older Connectors can continue polling. An operator's reverse proxy must allow the authenticated WebSocket upgrade for the new path to work. Inspect the active wake connection gauge and wake/poll counters together with Connector logs and a real read-only task; an open socket alone does not prove successful dispatch.
If wake connections drop but signed polling still dispatches tasks, investigate the proxy and network path. If polling is denied, investigate identity and policy instead. If dispatch succeeds but work never completes, inspect execution and receipt reporting. The metric names below are Prometheus series, not shell commands.
Presence updates are batched rather than rewriting capability data on every signed request. Lease traffic also helps keep long-running work visible. To assess user impact, measure submission, dispatch and completion for representative tasks; this release note does not claim a benchmark improvement without those measurements.
adc_node_wake_connections
adc_node_wake_total{outcome="attempted|offline"}
adc_node_poll_total{outcome="dispatched|idle|denied"}