Summary

• Problem: in queued run setup, messageProvider fallback used Surface before Provider when OriginatingChannel was missing.
• Why it matters: mixed relay metadata can carry Surface=webchat while the active channel is still Feishu, causing embedded runs to be mislabeled and downstream channel behavior to drift.
• What changed: switched fallback precedence to Provider -> Surface in get-reply-run, and added a regression test for Provider=feishu + Surface=webchat + missing origin metadata.
• What did NOT change (scope boundary): no routing policy changes, no dispatch logic changes, no channel adapter behavior changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Feishu channel: Message replies are routed to webchat instead of feishu #31859
• Related [Bug]: Webchat UI sends messages to wrong session when continuing a Feishu conversation #31573

User-visible / Behavior Changes

• Feishu turns with missing OriginatingChannel no longer fall back to webchat when context has Provider=feishu and Surface=webchat.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 + pnpm
• Model/provider: N/A
• Integration/channel (if any): Feishu + auto-reply queued run path
• Relevant config (redacted): N/A

Steps

1. Build queued run context with missing OriginatingChannel.
2. Set ctx.Provider="feishu" and ctx.Surface="webchat".
3. Inspect followupRun.run.messageProvider.

Expected

• messageProvider resolves to feishu.

Actual

• Before fix: resolved to webchat.
• After fix: resolves to feishu.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • pnpm test src/auto-reply/reply/get-reply-run.media-only.test.ts src/auto-reply/reply/agent-runner-utils.test.ts
  • Added regression test: prefers Provider over Surface when origin channel is missing.
• Edge cases checked:
  • Existing origin-precedence scenario still passes (uses inbound origin channel for run messageProvider).
• What you did not verify:
  • Live Feishu end-to-end on a real bot account.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly:
  • Revert this PR commit.
• Files/config to restore:
  • src/auto-reply/reply/get-reply-run.ts
  • src/auto-reply/reply/get-reply-run.media-only.test.ts
• Known bad symptoms reviewers should watch for:
  • messageProvider unexpectedly reverting to webchat in Feishu relayed contexts.

Risks and Mitigations

• Risk: contexts relying on legacy Surface-first fallback might observe different inferred provider when origin metadata is missing.
  • Mitigation: origin channel still has highest precedence; change only affects ambiguous fallback and is covered by regression tests.