[Fix] Auto-confirm an unanswered Discord routing card

[daniel-lxs]

Problem

A Discord routing card had no timeout. Ask someone where to run a task, get distracted, and 15 minutes later the pending route expired with its Redis TTL — no launch, no message, the request simply gone.

Slack auto-confirms its suggestion after 30s (runSlackAutoConfirm), Telegram after 5s (scheduleTelegramRoutingAutoConfirm). Only Discord dropped the request on the floor. This was the last behavioral divergence from Slack in the routing flow.

Reusing rather than re-deriving

The shared constant is renamed SLACK_AUTO_CONFIRM_TIMEOUT_MS → ROUTING_AUTO_CONFIRM_TIMEOUT_MS in @roomote/cloud-agents — which is already what block-kit.ts:2123 calls it in prose — and Discord imports the same 30s value. One constant, two providers, no third copy. (Telegram's local 5s is left alone; changing it is a product call, not this fix.)

The timer is in-process like both existing implementations, so a restart loses it and the route falls back to expiring exactly as it does today. Claiming the pending route is atomic (GETDEL), so a click and the timer cannot both launch.

A bug found on the way

The card announced "The best match is X" using options[0] — but on a fallback decision the options are merely alphabetical and the router had no opinion, so the card named a "best match" it had never chosen. Auto-confirming that would launch an alphabetical accident.

The suggested option is now located in the rendered list (never assumed to be first — a suggestion can vanish before the card is built) and stored as suggestedIndex. The card only claims a best match when one exists, and a fallback card auto-confirms nothing.

Replace-by-message, not replace-by-interaction

launchDiscordTask's replaceMessage described an interaction, but an auto-confirm has no interaction to answer through — nobody clicked. It now describes a message: a click is still answered via its token (that path is live-tested and untouched), while the timer edits the card by id.

Both go through replaceOrPostDiscordMessage, the Discord analog of Slack's postOrReplaceSlackMessage, which falls back to posting when the card is gone — so a started task never loses its cancel control.

Verification

245 tests pass across the Slack, Discord and Telegram handlers. New coverage, driven with fake timers:

• an unanswered card auto-confirms the suggestion and replaces the card by id
• a fallback card announces no match and auto-confirms nothing, even well past the timeout
• a route already claimed by a click is not launched twice

🤖 Generated with Claude Code

[roomote-roomote]

No new code issues found. See task

• apps/api/src/handlers/discord/replies.ts:55-60 Edit thread messages through the thread channel ID. cardChannel.channelId is the thread ID, but this passes parentChannelId to editMessage, so Discord returns Unknown Message; the fallback posts a second acknowledgement and leaves the routing card and buttons stale.
• apps/api/src/handlers/discord/routing-confirmation.ts:360-366 Do not resurrect a route claimed while the card post is completing. A fast Nevermind click can GETDEL the initial state before this unconditional second SET; this write recreates it, and the timer then auto-starts the canceled request. Use a conditional existing-key update, as the Telegram path does with XX.

_{Reviewed 88032d2}

[daniel-lxs]

Both real, both fixed in ca0f62c. Thanks — the second one would have been ugly in production.

1. Editing through the parent channel. Correct, and the failure mode is exactly the duplicate this flow just removed: the edit could only ever return Unknown Message, so the fallback would post a second acknowledgement beside a routing card still showing live buttons. The cause was copying postMessage's convention (channelId: parent, threadId: thread) to editMessage, which takes no separate thread id — a thread is itself a channel and the message lives in it. Now addressed by channel.channelId, with the returned result still reporting channelId/threadId the way postMessage does.

2. Resurrecting a claimed route. Also correct. The card id is only knowable after posting, so the route is written a second time, and that write was unconditional — a Nevermind landing in that window would have its GETDEL claim overwritten, and the timer would then launch the request the user just canceled. Now XX, so the write only ever updates a route that still exists. Telegram had already solved this and left a comment saying why; I copied its timer but not its storage semantics.

Tests added for both: a card in a thread is edited through the thread id (and posts only when the card is genuinely gone), and the second write is asserted to be conditional while the first is not.