[slack] 실행 중 런의 최종 응답이 요청 스레드가 아니라 전역 lastActive 슬롯으로 나간다

[cosmosjeon]

공통 인시던트 컨텍스트
2026-09-11 20:10:29 KST, Slack 채널 C0AKXLE61J5(#ceo_lead_align_input)의 스레드 1789104278.881179 에서 사용자가 봇을 멘션했다. 봇은 2초 뒤 "경과 531초 / 8분째 실행 중" 진행 카드를 올렸고(=이미 돌던 다른 런의 진행 상태), 약 3분 뒤 전혀 무관한 ReelBrain 티켓(exp3-cardnews-reunion-conditions, qa-delivery BLOCKED)의 ## Terminal phase summary 본문을 그 스레드에 게시했다. 게시된 두 메시지는 이후 수동 삭제했다.
로그: ~/.cli-jaw/logs/serve.log 19555-19670, jaw-serve.err. DB: ~/.cli-jaw/jaw.db messages 1666/1676/1677.
라벨 제안: 본문 상단 표기 참조.

제안 라벨: bug priority:P0 area:slack area:messaging

최종 응답 목적지가 요청 envelope가 아니라 lastActive 전역 슬롯에서 결정된다

요약

실행 중 런의 최종 텍스트가 그 런을 시작한 대화가 아니라, 가장 최근에 봇에게 말을 건 Slack 스레드로 나간다. 2026-09-11 20:10 KST 오배송은 웹 origin ReelBrain 런(b25ca0b8)의 종료 텍스트가, 방금 멘션이 덮어쓴 lastActive(C0AKXLE61J5 / ts=1789104278.881179)로 포워딩된 사례다.

재현·증거

1. 인바운드가 채널당 슬롯 1개를 즉시 덮는다. src/slack/bot.ts:1508-1509

setLastActiveTarget('slack', target);
setLatestSeenTarget('slack', target);

2. 웹 런 종료 agent_done에는 origin/text만 있고 target이 없다. src/agent/lifecycle-handler.ts:821 (print), :709-716 (native)

3. Slack agent_done 포워더는 페이로드가 아니라 지금 시점의 lastActive를 읽는다. src/slack/bot.ts:1822-1825, src/slack/forwarder.ts:70-76, src/messaging/forwarder-origin.ts:32-38

• origin === 'slack'만 skip. 웹/CLI는 통과.
• const target = opts.getLastTarget() → getLastActiveTarget('slack').

4. 이번 사건 원문

• DB messages 1666: role=user, cli=web, session=b25ca0b8 (exp3 qa-delivery)
• 1676: [👤 jun] 너도 한번 해봐! session=6c6e4301 created_at=2026-09-11 11:10:31 UTC
• 1677: ## Terminal phase summary … exp3-cardnews-reunion-conditions session=b25ca0b8 created_at=11:13:24
• serve.log:19555 [slack:in] C0AKXLE61J5: 너도 한번 해봐!
• :19565 [jaw:main] exited code=0, text=19613 chars
• :19566 {"event":"slack.post","target":"C0AKXLE61J5","threaded":true,"index":0,"of":1} — 같은 줄에 outbound.send / via:agent 없음 → dispatch/forwarder 직접 sendSlackText 경로.

가설: 멘션이 lastActive를 새 스레드로 바꾼 뒤, 웹 런 agent_done이 그 슬롯으로 포워딩되었다. 1677이 멘션 세션(6c6e4301)이 아니라 웹 세션(b25ca0b8)에 적재된 점이 이 가설과 맞다.

원인 분석

목적지가 요청 envelope에 불변 고정되지 않는다.

경로	목적지 확정 시점	소스
Slack origin dispatch (deliverSlackTurnBody)	인입 시 캡처한 target	요청 스코프. 이번 1677 경로 아님
POST /api/channel/send (sendChannelOutput)	전송 시	explicit → turn_conversation → lastActive → latestSeen
agent_done Slack forwarder	전송 시	전역 lastActive만. 이번 건의 주 경로

lastActiveTargets는 프로세스 전역 Map이다 (src/messaging/runtime.ts:91-101). 실행 중 다른 멘션이 오면 슬롯이 바뀌고, 끝나지 않은 웹/CLI 런의 최종본이 새 대화로 새어 나간다. turn_conversation(#474)은 에이전트가 echo할 때만 보호되고, forwarder는 그 값을 보지 않는다.

target-reply-guard가 못 막은 이유

admitTargetReply (src/messaging/target-reply-guard.ts:74-90)는 orchestrate_done 고아 waiter 입학 필터다.

• type !== orchestrate_done → agent_done은 즉시 null
• data.origin !== slack → 웹 origin 거부
• fromQueue|fromSteer|replyViaTarget 없으면 거부

목적지 일치 검사도, lastActive 포워더 차단도 없다. 이번 페이로드는 세 조건 모두 실패해서 가드 밖으로 지나갔고, lastActive forwarder가 그대로 보냈다.

수정 제안 (request-scoped destination binding)

1. 런 시작 시 destination을 불변 스냅샷으로 고정. SpawnOpts.target / setCurrentMainMeta에 이미 있다. 이후 inbound가 lastActive를 바꿔도 런 스냅샷은 불변.
2. 모든 agent_done에 그 스냅샷 target을 실어라. lifecycle-handler.ts 전 호출부 (특히 709, 821).
3. createSlackForwarder는 data.target만 사용. getLastActiveTarget 삭제. target 없는 웹/CLI 런은 Slack에 보내지 말 것 (UI가 목적지). lastActive는 사용자가 지금 보는 방이 아니다.
4. sendChannelOutput: 에이전트 표면은 allowActiveFallback: false. target/turn_conversation 없으면 실패. echo는 힌트가 아니라 필수 바인딩.
5. 대안: forwarder를 없애고 Slack origin만 envelope dispatch. 웹 답을 Slack에 미러링하는 기능은 사라지지만 오배송은 줄어든다.

영향 범위

• 웹/CLI 런 + Slack lastActive 포워딩 (이번 사고 유형)
• 에이전트가 target을 생략한 /api/channel/send (인바운드 턴 응답이 DM 대신 lastActive 공개 채널로 배달된다 (동시 턴 경합) #474 잔여)
• heartbeat 등 allowActiveFallback: false 경로는 이미 제외 (하트비트 리포트가 지정 채널이 아니라 lastActive 스레드로 배달된다 #437)

검증

• 웹 런 실행 중 다른 Slack 스레드 멘션 → 웹 최종본이 그 스레드에 없으면 pass, lastActive로 가면 fail
• agent_done fixture에 target 없음 → Slack post 0
• target 있는 런은 인입 후 lastActive가 바뀌어도 원래 thread_ts로만 post
• 회귀: tests/unit/turn-conversation-routing.test.ts, Slack origin 턴의 자기 스레드 dispatch는 유지

관련 이슈 후보

• 진행 카드가 새 스레드에 경과 531초로 붙은 현상 (progress lifecycle vs live-run 혼선)
• pabcd IDLE에서 다른 세션 런이 같은 [jaw:main] 슬롯으로 재개되는 세션 키/스코프 붕괴
• orchestrateAndCollect가 requestId 없는 orchestrate_done을 새 waiter가 집는 fail-open

---

같은 인시던트에서 갈라진 이슈: #743 · #744 · #745

[cosmosjeon]

선행 사례 비교(openclaw/openclaw, NousResearch/hermes-agent 얕은 클론 실측). #743 #744 와도 연결됨.

Slack 오배송 선행사례 — OpenClaw / Hermes 요청-응답 바인딩

cli-jaw 사고(web-origin 최종문이 전역 lastActive로 CEO 스레드에 게시, 진행카드 혼선, scope=default 단일 슬롯 steer)를 로컬 클론 openclaw·hermes3와 대조. 둘 다 Slack 연동 있음. 레포 수정 없음.

1. 목적지는 요청 시점에 턴에 고정

OpenClaw: inbound가 OriginatingChannel/OriginatingTo/MessageThreadId를 찍는다(inbound-event/context.ts:581-586, OriginatingTo=reply.originatingTo??reply.to). Slack prepare.ts:1174-1178,1647-1650이 replyRouteTarget(user:|channel:)과 boundMessageThreadId를 넣는다. 세션 키는 ResolvedAgentRoute.sessionKey(resolve-route.ts:63-87)+resolveThreadSessionKeys(session-key.ts:329-347)=agent::slack:channel:[:thread:]. 최종 전송은 이 턴의 threadTs/OriginatingTo. lastRoute는 cron/후속 메타이지 완료 경로가 아니다(templating.ts:405-418).

Hermes: SessionSource(session.py:64-99: platform,chat_id,thread_id,scope_id,message_id,user_id). build_session_key(source)(641-685)=::<chat_type>[:slack scope_id][:chat_id][:thread_id][:user]. 회신은 adapter.send(source.chat_id, metadata=_thread_metadata_for_source(source))(run.py:4051-4067, run_notifications.py:128,393-397). SessionEntry.origin은 cron origin용.

2. 동시 런은 세션 키로 격리

OpenClaw 큐는 sessionKey 단위(get-reply-run-queue.ts). registerSlackSessionRun이 (teamId,channelId,threadTs)에 route.sessionKey를 등록하고, captureSlackSessionTargetGuard는 sessionId+lifecycleRevision이 같아야 Stop/상태 권한을 준다(session-run-targets.ts:18-87). Hermes는 _running_agents[session_key]와 await 전 _AGENT_PENDING_SENTINEL(run.py:2183-2185). 같은 세션 후속만 _pending_messages 1슬롯 병합+/queue FIFO. 스트림 수신자는 턴의 source.user_id/scope_id를 찍고 chat_id 캐시가 덮어쓰지 못하게 했다(test_slack_turn_recipient_identity.py).

3. 진행 소유권

OpenClaw는 디스패치 클로저의 draftStream.messageId()와 이 턴의 streamThreadHint(dispatch-setup.ts:256-263). Hermes 상태 버블은 (chat_id,thread_ts,status_key)(adapter.py:2166-2179), 네이티브 카드는 (team,channel,thread)(1894-1919). 둘 다 runId 없음. _active_streams는 chat_id만 키(971-973)라 같은 채널 동시 스트림이 섞일 수 있다.

4. cli-jaw 결함 3개

(1) agent_done에 목적지 없음+getLastActiveTarget → 완료 이벤트에 OriginatingTo+thread_ts+sessionKey 또는 SessionSource를 실어라. lastRoute/origin은 그 세션의 나중 배달용. 전역 lastActive·Telegram last-active topic 재기록(run.py:3848-3859) 금지.

(2) 진행카드가 requestId/sessionId 없이 매칭 → 런이 자기 messageTs를 들고 편집(OpenClaw). (channel,thread)/chat_id만 쓰면 같은 스레드 두 런이 elapsed를 공유한다. 키에 requestId 또는 sessionId+runId.

(3) scope=default 단일 슬롯 steer → 실행 슬롯을 채널+스레드(+Slack scope_id) 세션 키로 쪼개고 같은 키만 큐/steer. dmScope=main으로 DM을 agent:main에 접는 패턴과, _pending_messages 덮어쓰기를 다른 대화에 쓰는 것은 금지. web-origin과 Slack 멘션은 키가 달라야 하고 멘션이 기존 런에 steer로 얹히면 안 된다.

검증: A 런 중 B 멘션 → A 최종문이 B면 실패. 진행 elapsed가 다른 requestId면 실패. 두 대화가 한 run에 합쳐지면 실패.

[JSap0914]

Resolved by #746 and hardened by #748. agent_done delivery is request-scoped, targetless/cross-channel terminals fail closed, and the original last-active overwrite race is covered. Deployed in cli-jaw 2.17.49 (stable SHA 729f0dc). Live 3457 reports 2.17.49.