routeSpeech: connector publish errors/timeouts bypass the send-failed marker and trace #187

Summary

When a connector's channels/publish rejects (JSON-RPC error, 60 s request timeout, or transport drop mid-request), ChannelRegistry.routeSpeech throws instead of returning through its fail() helper. In locus mode every caller catches that throw and only writes to stderr. So:

• no [discord-send-failed] marker reaches the agent's context,
• no mcpl:speech-route-failed trace is emitted,
• the turn's [delivered] receipt leaves the segment out without comment.

The agent's reply disappears with no sign in its context. The marker currently fires only for host-side refusals (no locus, unregistered channel, missing grant, server not found) and explicit delivered:false. It does not fire for the failures connectors actually report.

Where

• routeSpeech awaits the publish without a try: channel-registry.ts#L2921
• sendRequest rejects on error response, timeout, and close: server-connection.ts#L952-L963, #L1170-L1173
• Locus-mode callers log and move on: framework.ts#L9212, #L9305, #L8520, #L7880

Which connector failures take this path

Every in-tree connector returns delivered as a boolean on success and on empty text, and throws on everything else. Examples:

• discord-mcpl / slack-mcpl: any platform API error (missing permission, rate limit, 5xx).
• zulip_mcp: an upload failure, or a chunked long reply where chunk k > 1 fails after earlier chunks were already posted. That is a partial delivery, reported to the host as an error.
• Any connector that hangs past 60 s. The timeout text already says the outcome is unknown, but it only reaches stderr.

Related

• The timeout and transport-drop cases are where delivery is genuinely uncertain. In explicit >>> mode the catch at framework.ts#L7853-L7857 bounces them as definitely failed and offers {{unsent}}, which can double-post.
• fix(mcpl): require explicit final speech delivery receipts #163 hardens the missing-receipt branch, but no in-tree connector produces that case. The uncertainty it describes lives on this path instead.

Suggested direction

Catch the publish rejection inside routeSpeech and route it through fail() with a reason that tells two cases apart:

• definite: the server returned an error response and nothing was posted,
• uncertain: timeout, transport close, or a partial chunked send.

Then have both the marker and the >>> bounce use that distinction. A marker-per-failure test with a rejecting fake server would cover it.