fix(messaging): resolve message-to-event 404 for outgoing events without incomingEventId

[mnbreno]

Summary

• The GET /api/v1/bots/:botId/messaging/message-to-event/:messageId endpoint returns 404 for outgoing events that lack incomingEventId. In production, 63% of outgoing events (26/41) have this field empty, causing constant spurious 404s in Studio and HITL debugger.
• Root cause: the handler unconditionally does a second findEvents({ incomingEventId: ... }) lookup, which fails when the field is empty/null.
• Fix: three-tier resolution in the route handler:
  1. If the matched event is already incoming → return it directly.
  2. If outgoing with a valid incomingEventId → follow the chain (existing behavior, preserved).
  3. Otherwise → return the outgoing event itself as graceful degradation instead of 404.

Changed file

• packages/bp/src/core/messaging/messaging-bot-router.ts — 18 insertions, 8 deletions in the /message-to-event/:messageId route handler.

Reproduction

1. Send messages through a bot on any channel.
2. Open Studio debugger or HITL panel.
3. Observe repeated 404 on message-to-event/<messageId> in the network tab for outgoing (bot-reply) messages.
4. Verify in the DB: SELECT direction, "incomingEventId" FROM events WHERE "messageId" = '<uuid>'; — outgoing events have empty incomingEventId.

Test plan

• Outgoing event without incomingEventId → returns 200 + event JSON (was 404).
• Outgoing event with incomingEventId → returns 200 + incoming event JSON (unchanged behavior).
• Incoming event → returns 200 + event JSON directly (new fast path).
• Non-existent UUID → still returns 404 (no false positives).
• Studio debugger shows no new 404s on message-to-event after fix.

Made with Cursor