Extension command.execute can be accepted but never delivered, hanging slash-command invocation
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 38/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- javascript
调研方向
从 runtime 命令事件路由路径开始,重点检查目标所有者解析、publish_session_event、post_response_notifications、gated_sessions 以及等待待处理命令响应的逻辑。跟踪扩展的重新加载/恢复流程,并为立即调用 slash 命令添加所要求的回归覆盖;完成的标准是 command.execute 到达其所有者并完成,或者传递失败能够及时通过一个可采取行动的错误得到解决。
由索引模型根据 Issue 内容生成。
描述
Drafted by GIthub Copilot with human review.
Summary
An extension slash command can be recognized by Copilot CLI and dispatched as command.execute, yet never reach the owning extension handler. The invocation then hangs silently because the runtime waits indefinitely for session.commands.handlePendingCommand and no timeout or delivery error is surfaced.
This is exposed through the public extension SDK, but the captured failure occurs in runtime command-event routing before SDK handler entry. Please triage as a runtime-root-cause bug.
Environment
- Copilot CLI:
1.0.84-8 - OS: Windows 11
- Extension API:
@github/copilot-sdk/extensionviajoinSession({ commands: [...] }) - Reproduced: September 15, 2026
Reproduction
-
Load an extension that registers a slash command through
joinSession, for example:await joinSession({ commands: [{ name: "bookmarks", description: "Open the session bookmark manager", handler: async () => { // Instrument handler entry here. }, }], }); -
Reload extensions.
-
Confirm the extension reaches
=== ready ===and can service another registered callback. In this reproduction, its canvas provider successfully handled rehydration. -
Invoke
/bookmarksinteractively.
Actual behavior
- CLI recognizes and invokes the registered slash command.
- Runtime emits
command.executeevent ID537170aa-2e69-41b6-a37b-ad0e505ea166. - The detached host-delivery queue starts and reports successful completion.
- The owning extension never enters the command handler.
- No
command.completedevent is emitted. - No
No client found for commanderror is emitted. - The invocation remains pending indefinitely without user-visible failure.
Relevant runtime timeline:
2026-09-15T08:44:56.142Z slash_command_invoked
2026-09-15T08:44:56.143Z Detached host delivery started
delivery_kind="reserved_event"
event_type="command.execute"
event_id="537170aa-2e69-41b6-a37b-ad0e505ea166"
2026-09-15T08:44:56.146Z Detached host delivery completed
2026-09-15T08:44:56.146Z Detached host delivery retirement decision completed
Temporary instrumentation around command-handler entry, session.rpc.canvas.open, and the canvas provider confirmed that neither the command handler nor downstream canvas call was reached. The same extension process had successfully handled canvas-provider rehydration approximately 35 seconds earlier.
Expected behavior
One of the following should happen deterministically:
command.executereaches the registered owner, the handler runs, andcommand.completedresolves the invocation; or- Delivery failure/disconnection is detected and the pending invocation fails promptly with an actionable error.
A request-like control-plane event must not be considered successfully delivered merely because it was queued somewhere that may never drain.
Suspected runtime area
Runtime source currently:
- resolves a targeted owner for
command.execute; - calls
publish_session_eventfor that connection; - treats an event queued in
post_response_notificationsbehind agated_sessionsdispatch token as successfully published; and - waits on the pending command response without a timeout.
This makes a stale or unreleased create/resume response gate one plausible mechanism: publication reports success, so no undelivered-command rejection occurs, but the owner never receives the event. The logs do not expose the connection ID or gate token, so this is a hypothesis rather than a proven precise race.
Relationship to #2368
This appears to be a sibling or incomplete-fix path for #2368, not necessarily the identical implementation defect:
- #2368 concerned lost
external_tool.requestedevents and SDK event-forwarder lag. - This reproduction concerns targeted
command.executedelivery after extension reload. - Both turn a lost request-like event into an indefinite hang because no timeout or disconnect failure resolves the pending request.
Requested fix
- Guarantee delivery or explicit rejection for targeted
command.executeevents. - Do not treat indefinitely gated notifications as successful delivery.
- Add a bounded timeout/disconnection failure for pending command execution as defense in depth.
- Add a regression test covering extension reload/resume followed by immediate slash-command invocation.
- 主要语言
- Java
- 星标
- 10.5k
- 派生
- 1.5k
- 平均合并
- 1 天 12 小时
- 30 天内合并 PR
- 133
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
github/copilot-sdk 的其他 Issue
-
agentic-workflows
难度 2/5 1-3 小时 新手友好度 68/100
github/copilot-sdk#2709 · 1 条评论 ·
-
难度 1/5 1 小时以内 新手友好度 78/100
github/copilot-sdk#2673 ·
-
bug testing
难度 2/5 1-3 小时 新手友好度 75/100
github/copilot-sdk#2628 ·
-
agentic-workflows
难度 2/5 1-3 小时 新手友好度 68/100
github/copilot-sdk#2627 · 1 条评论 ·
-
agentic-workflows
难度 2/5 1-3 小时 新手友好度 74/100
github/copilot-sdk#2493 ·
查看 github/copilot-sdk 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
infinispan/infinispan#18150 ·
-
难度 2/5 1-3 小时 新手友好度 84/100
-
untriaged
难度 2/5 1-3 小时 新手友好度 82/100
opensearch-project/k-NN#3597 ·
-
bug
难度 2/5 1-3 小时 新手友好度 88/100
-
bug
难度 2/5 1-3 小时 新手友好度 82/100