Message delivery delay in Assign pattern when Supervisor receives multiple async callbacks

[Kwak-Jihyun]

Kiro CLI: Message delivery issues in Assign pattern

Category: Bug Report / Discussion

---

Scenario

Using the Assign (Async) Pattern where a Supervisor spawns multiple workers in parallel:

Supervisor → 3 Data Analysts (assign - async/parallel)
Data Analysts → Supervisor (send_message - async callback with results)

Problem

When Data Analysts complete their work and send results back to the Supervisor:

1. Data Analyst A sends result → queued
2. Data Analyst B sends result → queued
3. Data Analyst C sends result → queued
4. Supervisor is IDLE, waiting for messages
5. Messages never delivered - queue keeps growing but Supervisor receives nothing

The Supervisor was clearly idle and ready to receive, but queued messages were not being delivered.

---

Root Cause Analysis

After debugging, I found two issues:

Issue 1: Idle Pattern Mismatch (Bug)

The IDLE_PROMPT_PATTERN_LOG in kiro_cli.py uses a hardcoded ANSI color code that doesn't match Kiro CLI's actual terminal output:

# Current pattern (kiro_cli.py)
IDLE_PROMPT_PATTERN_LOG = r"\x1b\[38;5;13m>\s*\x1b\[39m"

Actual Kiro CLI output (from log file):

\x1b[38;5;93m> \x1b[0m

Differences:

• Pattern expects color code 13, actual is 93 (or other values)
• Pattern expects \x1b[39m reset, actual uses \x1b[0m

This caused _has_idle_pattern() to always return False, blocking all message delivery.

Proposed Fix:

IDLE_PROMPT_PATTERN_LOG = r"\x1b\[38;5;\d+m>\s*\x1b\[0m"

Issue 2: Event-Driven Delivery Dependency (Design Limitation)

After fixing Issue 1, I noticed another limitation. Message delivery only triggers on log file modification events:

# PollingObserver watches for log file changes
inbox_observer.schedule(LogFileHandler(), str(TERMINAL_LOG_DIR), recursive=False)

If the receiver terminal is idle with no activity, log file doesn't change, and queued messages won't be delivered until some other activity occurs.

In practice, this is less critical because ongoing terminal activity (processing messages, user interaction) keeps triggering delivery attempts. But in edge cases where a terminal is completely idle, messages could be delayed indefinitely.

[haofeif]

@Kwak-Jihyun there were some bugs in the Jan version, but there were recent fixes in v1.1.0. Is it something that you could try again with the latest release from main branch to see whether your issue still exist