github / github/copilot-cli

Queued user messages + system_notifications delivered out of send order

未关闭
#3,517 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
area:agents
主要语言
Shell
星标
11.2k
派生
1.9k
平均合并
14 小时 16 分钟
30 天内合并 PR
6

描述

## Summary

When the assistant is mid-tool-call and the user sends multiple messages and/or `system_notification`s arrive in that window, the queued items are delivered to the assistant in a non-deterministic / out-of-send-order sequence.

## Observed behaviour

In a long session that drives many background agents and async shells (typical of orchestration/supervisor workflows), the user types several short messages while a tool call is in flight (e.g. "and?", "bump", "why why why", "check again"). When the tool call returns and the assistant's next turn begins, the messages are NOT presented in the order they were sent.

Symptom from inside the loop: an older message can appear after a newer one, system_notifications interleave seemingly arbitrarily with user messages, and the assistant cannot reliably tell which user prompt is the "latest" intent.

## Expected behaviour

Queued user messages and system notifications should be delivered to the assistant in strict send-time order (FIFO per channel, or globally ordered by enqueue timestamp). At minimum, the assistant should be able to read a monotonic timestamp on each so it can re-sort.

## Impact

- The assistant answers a stale message as if it were the latest, ignoring follow-ups.
- In an operator-driven loop (supervised PR dispatch, multi-agent orchestration) the user can't trust the assistant heard the most recent instruction.
- Causes the user to repeat themselves and escalates frustration.

## Two related observations (may be the same root cause or separate)

1. **Two queues, not one.** There appear to be two delivery channels (user messages and `system_notification`s) and they are interleaved with no obvious total order. A single ordered queue would be simpler to reason about.
2. **No visible enqueue timestamp.** Each `` includes a `` that looks like the *delivery* time, not the *send* time. So even if the assistant wanted to re-sort, it lacks the data.

## Repro

1. Start a session that dispatches a 2–5 minute background tool call.
2. While it's running, send 3–5 short user messages, each ~10 s apart.
3. When the tool completes, observe the next assistant turn — the messages are not always processed in send order.

## Suggested fix

- Single FIFO queue across user messages + system_notifications, OR
- Tag each delivered item with a monotonic `enqueuedAt` so the assistant can sort, AND
- Document the ordering guarantee in the agent docs.

## Environment

- GitHub Copilot CLI v1.0.54
- Windows
- Long-running multi-agent session

## Refs

Filed at operator's explicit request after the issue reproduced multiple times in a single session.

贡献指南

打开贡献指南

调研方向

该 issue 未指出源文件、测试或入口点。首先,在用户消息和 system_notifications 已排队的长时间运行工具调用期间重现排序失败;当交付顺序是确定性的,或每个项目都暴露足够的入队时数据以确定顺序,并且该保证已记录且由回归测试覆盖时,即视为完成。

由索引模型根据 Issue 内容生成。

评估

技术栈
shell
领域
cli
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
冷清
描述清晰度
基本清楚
新手友好度
45/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。