[factory] Slack thread replies never reach the babysitter — the dispatch thread is one-way

[khaliqgant]

Summary

A human replying in the Slack dispatch thread should reach the issue's babysitter. It does not. The reply lands in Slack, nothing routes it, and the agents that own the work never see it.

What happened

Factory posted its dispatch notification for AgentWorkforce/cloud#3045:

3045: factory agents dispatched.
State: dispatching · Agents: ar-3045-impl-cloud, ar-3045-review-cloud

The principal replied in that thread:

@agent Relay there is unaddressed pr feedback here and failing ci

That is exactly the intended interaction — a human noticing something wrong and saying so where the notification lives, rather than hunting for the right agent. It produced no action. ar-3045-babysit-cloud and ar-3045-review-cloud were both alive at the time and neither reacted.

The observation was correct, incidentally: cloud#3049 had three unaddressed review findings (one 🔴 bug, one 🟨 security, one 🟡 correctness) and two failing CI checks. So the human was right and the channel was the problem.

Why this should work through the relayfile mount

Slack is already a relayfile-projected provider. Thread replies land in the mount as files under the channel/thread tree, and the writeback contract runs the other way. So the routing primitive exists — a reply is a file appearing at a path that is already associated with the dispatch thread.

Factory also already tracks the association. src/orchestrator/factory.ts:

• #postAndWatchSlackDispatchThread posts the dispatch message and stores the thread id
• this.#state.setSlackThread(this.#workspaceId, issueKey(record.issue), root.threadId)
• #ensureSlackConversationSession(record, root.threadId)
• #watchSlackThread(record, root.threadId)

So the thread id is persisted against the issue key and a watcher is registered. The gap is between that watcher firing and the babysitter being woken with the reply.

Asked-for behaviour

1. A reply in a Factory dispatch thread reaches the babysitter for that issue. The thread→issue mapping already exists in state; use it.
2. Route through the relayfile mount rather than a separate Slack API path. The projection is the coordination substrate, and a second ingestion path would drift from it.
3. Acknowledge in-thread. A human who replies and gets silence cannot tell whether the message was received, whether an agent is working, or whether the feature exists. Even a reaction closes that loop.
4. Fail loudly if routing cannot happen — no live babysitter, no thread mapping, agent unreachable. Silence is the current behaviour and it is indistinguishable from "working on it."

Definition of done

• A reply in a dispatch thread demonstrably reaches the babysitter for that issue, verified by the agent acting on it, not by a log line saying it was sent.
• The human sees an acknowledgement in-thread.
• A reply that cannot be routed produces a visible error rather than silence.

Verification — against a real thread

Do not close this on a unit test asserting a message was dispatched.

Dispatch an issue, reply in its Slack thread, and show the babysitter receiving and acting on it. Attach the thread and the agent's response.

Notes

• Related: factory#269 covers the content of these notifications (bare issue numbers, no repo, no link). This issue covers the return path. Both are about the dispatch thread being a real interface rather than a one-way log.
• The specific findings the principal was pointing at are in cloud#3049 and are being addressed separately.
• mergePolicy: never — open the PR and stop at review.
• Branch from origin/main.

[khaliqgant]

Pre-implementation design (verified against origin/main@eaaa076)

First, a call-graph correction: the premise in the initial diagnosis is no longer true on current origin/main. #watchSlackThread has two direct callers: the dispatch path (#postAndWatchSlackDispatchThread, call at current line 13368) and the escalation path (#postAndWatchSlackEscalationThread, call at current line 13943). Startup rearm also already covers active in-flight dispatch records and durable Slack conversation sessions. I will preserve that machinery rather than add a second dispatch ingestion path.

The live gap is now: routing ownership can disappear, the no-owner path increments an internal counter and returns silently, no acknowledgement is written to the human's thread, and the pre-dispatch triage shape from #227 is still absent from startup rearm.

1. Recipient and no-owner behavior

Use exactly one conversation owner to avoid duplicated/conflicting action:

• once a PR babysitter has a resumable session, the babysitter owns the thread;
• before that handoff, the implementer is the fallback owner;
• the reviewer does not receive a duplicate copy automatically; the babysitter may re-engage review as part of shepherding the PR;
• if an active work unit temporarily has no resumable owner, durably retain the full reply and visibly say in-thread that Factory received it but is waiting for an owner; retry when the babysitter/implementer is restored;
• if the work unit is terminal and Factory can no longer route it, write a visible error in the same thread pointing the human to the durable issue/PR surface. Do not count-and-drop.

The existing implementer→babysitter conversation-session rebind remains the handoff mechanism.

2. Delivery without Relay DM truncation

Do not inject the reply with Relay send_dm. Persist the complete Slack message in the durable ConversationSessionState queue and resume the owning agent with a fresh task whose body includes every complete coalesced message. Current slackConversationResumeTask already follows this shape and explicitly avoids live PTY/session injection. I will add a discriminating long-message test (>80 characters) that asserts the tail arrives intact at the babysitter.

Only acknowledge receipt after durable enqueue succeeds. A state-store failure remains unacknowledged and replayable; resume failures retain the claimed turn, release its lease, log/counter the failure, and retry.

3. Watch arming, bounds, and busy-channel behavior

Arm immediately after the dispatch root and thread→work-unit mapping are durably stored. Keep one watcher per active work unit, keyed by issue, until the work unit reaches its terminal lifecycle; on restart, rebuild it from durable state. The existing exact channelDir + threadTs predicate prevents unrelated-thread routing, the bot guard prevents writeback loops, and message-id/state dedupe makes eventual duplicate delivery safe.

This is bounded by the active work-unit set, not Slack history. A busy channel may deliver many candidate events, but each watcher reads/routes only the exact persisted thread and coalesces rapid human replies into one turn. I will keep persisted additions small and work-unit keyed. If fleet scale later makes per-work-unit subscriptions expensive, the safe optimization is one channel fan-out subscriber indexed by durable thread id; that is not required for this focused fix.

4. #227

I will fix #227 in the same change. slackThreadIds is necessary but not sufficient by itself: it maps issue key→thread id, but a pre-dispatch triage escalation is not in batch.inFlight, and the map alone does not reconstruct the TriageDecision needed to route the answer. The existing durable GitHub issue-comment watch already stores the triage decision. Startup rearm can iterate those kind: triage records, look up the Slack thread id, rebuild escalationWatchRecord(decision), and replay a human reply that arrived while Factory was stopped. That adds no duplicate decision document and keeps state small.

Discriminating pairs to prove

• dispatch thread human reply → babysitter; unrelated thread → no route;
• long reply tail preserved → no ~80-character fragment;
• pre-existing dispatch thread after restart → babysitter; bot reply after restart → no route/loop;
• triage reply received while stopped → rearmed and dispatched after restart (Triage-escalation Slack replies are dropped after a daemon restart (watcher never rearmed) #227); unrelated/unmapped triage thread → no route;
• transient durable enqueue failure → retry then one delivery; terminal/no-owner reply → visible failure, never silent success.

I will red-check the new restart tests by applying the test-only patch to a separate scratch worktree at the unmodified base, then verify the implementation by command exit code.

[khaliqgant]

Small correction after inspecting the persistence adapter: slackThreadIds is durable only for the lifetime of an InMemoryStateStore object; FileStateStore does not serialize that map. Dispatch restart happens to recover from ConversationSessionState.externalId, but pre-dispatch triage has neither a conversation session nor a durable thread id. Therefore #227 needs a compact persisted Slack watch record containing { issue, decision, threadId, kind: triage }, keyed by the work unit. Startup will iterate that record directly. This is stricter than the initial design note and avoids any laptop-local/ephemeral-map dependency.

[khaliqgant]

Implemented in #287: #287

Final design/results:

1. Recipient: the PR babysitter is the single owner once it exists; the implementer is the fallback before that handoff. Reviewers are not fanned out because that creates competing owners. If neither has a resumable session yet, Factory durably queues the complete reply and binds it when the babysitter/implementer becomes resumable. After all agents exit, the exact dispatch listener remains for a bounded 24-hour grace period and posts an explicit no-active-agent response instead of silently dropping a reply.
2. Delivery: no Relay DM injection is used. The full Slack text is appended to the durable conversation and delivered through fleet.resume, so text beyond the DM truncation boundary is retained. Factory writes a visible Slack receipt only after durable enqueue; receipt claims are themselves persisted and leased so a write failure stays retryable without concurrent duplicate acknowledgements.
3. Watcher scope/lifetime: one listener per active work unit, filtered to the exact channel/thread and retaining the bot guard. It lasts through dispatch and a 24-hour terminal grace, then expires and removes its small keyed record. A reopened work unit explicitly retires the old grace listener before establishing a new dispatch thread.
4. Triage-escalation Slack replies are dropped after a daemon restart (watcher never rearmed) #227/restart: fixed in the same PR. slackThreadIds was not sufficient because FileStateStore does not serialize that inherited in-memory map. The PR adds compact durable triage/terminal watch metadata and startup rearming/replay. Active dispatch conversations already provide their durable restart identity and now also cover ownerless threads.

Observability/retry behavior is preserved: an event is marked seen in memory only after durable routing and the visible receipt succeed; state/writeback failures remain replayable through polling/restart. Bot replies and unrelated threads remain must-not-fire cases.

Verification:

• full orchestrator suite: 490/490
• file state suite: 29/29
• build and feature-map check: pass
• test-only red check on eaaa076: triage restart, receipt retry, and ownerless long-reply tests all failed before implementation
• the four unrelated tests that timed out under the earlier repository-wide parallel run all passed independently

The requested Veto MCP diff-review tool was not exposed in this worker lane; I recorded the fallback build/tests, manual diff review, diff hygiene, and secret-pattern scan in the PR.

[khaliqgant]

Final gate update for #287:

• all repository checks pass: package, Kubernetes provider E2E, load E2E, verification-gate E2E, and verification-stack E2E
• Cubic and CodeRabbit pass
• all three automated review findings were addressed and their threads resolved
• follow-up coverage now also proves (a) a reply acknowledged during the coalescing window is visibly surfaced before terminal cleanup, (b) already-routed historical replies are not mislabeled during restart replay, and (c) a legacy terminal watch without the new watermark is durably migrated before replay
• latest local verification: build pass, feature-map pass, state suite 29/29, focused migration/race/clarification cases pass; the full orchestrator run on the review-fix commit passed 491/491

PR remains unmerged for Khaliq's gate: #287

[khaliqgant]

Post-rebase final gate for #287:

• rebased cleanly onto current main (4f619e9, Expose a host-neutral document state-store port #285) and integrated Slack persistence into the new host-neutral document-store parser
• fixed two additional valid review findings: expired unowned delivery claims now persist their requeue, and legacy delivered history is migrated to suppress duplicate startup receipts while pending work remains receipt-eligible
• intentionally retained one visible terminal response per human reply: suppressing later responses would violate this issue's explicit per-reply observability/no-silent-drop requirement; bot filtering, exact-thread scope, and the 24-hour bound constrain noise
• all review threads are resolved
• final GitHub checks all pass: package, Kubernetes provider E2E, load E2E, verification-gate E2E, verification-stack E2E
• local post-rebase checks: build pass, feature-map pass (319 features), four state/document suites 46/46, focused Slack/restart/clarification cases pass, clean diff and secret-pattern scan
• PR is clean against current main and remains unmerged for Khaliq's gate

#287