feat(github-copilot-sdk): bump version to v0.11.0 for performance & stability

- Fixed shared client pool bug to eliminate TTFT latency.
- Added pure BYOK-only mode support.
- Improved cross-user environment isolation for concurrency.
- Resolved RichUI infinite vertical sizing loop.
- Integrated client.ping() into stall detection.
- Automatically hide TODO List widget after completion.
- Synced all documentation and release notes.
This commit is contained in:
fujie
2026-03-20 03:26:43 +08:00
parent bf3ba97b9a
commit 6f8c871658
17 changed files with 2862 additions and 123 deletions

View File

@@ -44,3 +44,6 @@ Edge cases or caveats to watch out for.
| [openwebui-tool-injection.md](./openwebui-tool-injection.md) | How OpenWebUI injects parameters into Tool functions, and what the Pipe must provide |
| [openwebui-mock-request.md](./openwebui-mock-request.md) | How to build a valid Mock Request for calling OpenWebUI-internal APIs from a Pipe |
| [copilot-plan-mode-prompt-parity.md](./copilot-plan-mode-prompt-parity.md) | Why Plan Mode prompt logic must be shared between fresh-session and resume-session injection |
| [richui-default-actions-optout.md](./richui-default-actions-optout.md) | How static RichUI widgets opt out of fallback prompt/link action injection |
| [richui-declarative-priority.md](./richui-declarative-priority.md) | How RichUI resolves priority between declarative actions and inline click handlers |
| [richui-interaction-api.md](./richui-interaction-api.md) | Recommended 4-action RichUI interaction contract for chat continuation, prefill, submit, and links |

View File

@@ -0,0 +1,72 @@
# GitHub Copilot SDK 卡顿/悬停问题深度源码分析报告
## 📌 问题现象
用户反馈在 agent 处理过程中(工具调用、思考、内容输出),`github_copilot_sdk.py` 管道偶尔会卡住(界面转圈不停)。
## 🔍 事件流架构SDK 源码分析)
通过阅读 `copilot-sdk` 源码 (`jsonrpc.py`, `client.py`, `session.py`),事件流路径如下:
```
Copilot CLI (subprocess)
└─ stdout (JSON-RPC over stdio)
└─ JsonRpcClient._read_loop() [daemon thread]
└─ _handle_message()
└─ notification_handler("session.event", params) [线程安全调度到 event loop]
└─ CopilotSession._dispatch_event(event)
└─ plugin handler(event) → queue.put_nowait(chunk)
└─ main loop: await queue.get() → yield chunk
```
## 🚨 已确认的三个卡顿根因
### 根因 1: Stall 检测豁免盲区
原始代码的防卡死检测仅在 `content_sent=False``thinking_started=False``running_tool_calls` 为空时才触发。一旦 agent 开始处理(输出内容/调用工具),所有豁免条件为真,防卡死机制永久失效。
### 根因 2: 工具调用状态泄漏
`running_tool_calls.add(tool_call_id)``tool.execution_start` 时添加,但如果 SDK 连接断开导致 `tool.execution_complete` 事件丢失,集合永远不为空,直接阻塞 Stall 检测。
### 根因 3: `session.abort()` 自身可能卡住SDK 源码确认)
**SDK 源码关键证据** (`jsonrpc.py:107-148`):
```python
async def request(self, method, params=None, timeout=None):
...
if timeout is not None:
return await asyncio.wait_for(future, timeout=timeout)
return await future # ← 无 timeout永久等待
```
`session.abort()` 底层调用 `self._client.request("session.abort", ...)` **没有传 timeout**
当 CLI 进程挂死但 `_read_loop` 尚未检测到断流(例如 TCP 半开连接),`abort()` RPC 自身会无限等待响应,造成**修复代码自身也卡住**。
## ✅ 修复记录 (2026-03-18)
### 修复 1: `assistant.turn_end` / `session.error` 兜底清理
`running_tool_calls.clear()` — 即时清除孤儿工具状态。
### 修复 2: 绝对不活跃保护 (Absolute Inactivity Guard)
当距最后一个事件超过 `min(TIMEOUT, 90) × 2 = 180s` 且无任何新事件时,**无条件**推送错误并结束流。不受 `content_sent` / `thinking_started` / `running_tool_calls` 任何豁免条件限制。
### 修复 3: `session.abort()` 超时保护
所有 `session.abort()` 调用使用 `asyncio.wait_for(..., timeout=5.0)` 包裹。即使 abort RPC 自身卡住也不会阻塞主循环。
## 📊 修复后超时时间线
| 场景 | 保护机制 | 触发时间 |
|------|----------|----------|
| Turn 开始后完全无事件 | Primary Stall Detection | 90 秒 |
| Agent 处理中突然断流 | Absolute Inactivity Guard | 180 秒 |
| abort() 调用本身卡住 | asyncio.wait_for timeout | 5 秒 |
| Turn 结束/Session 错误 | 兜底 running_tool_calls.clear() | 即时 |
---
*Created by Antigravity using Source-Code-Analyzer skill on 2026-03-18.*

View File

@@ -0,0 +1,27 @@
# RichUI Declarative Priority
> Discovered: 2026-03-16
## Context
This applies to the RichUI bridge embedded by `plugins/pipes/github-copilot-sdk/github_copilot_sdk.py` when HTML pages mix declarative `data-openwebui-prompt` / `data-prompt` actions with inline `onclick` handlers.
## Finding
Mixing declarative prompt/link attributes with inline click handlers can cause duplicate prompt submission paths, especially when both the page and the bridge react to the same click.
## Solution / Pattern
The bridge now treats inline `onclick` as the default owner of click behavior. Declarative prompt/link dispatch is skipped when an element already has inline click logic.
If a page intentionally wants declarative bridge handling even with inline handlers present, mark the element explicitly:
```html
<button
onclick="trackClick()"
data-openwebui-prompt="Explain this chart"
data-openwebui-force-declarative="1"
>
```
## Gotchas
Without the explicit override, keyboard/click dispatch for declarative actions will yield to inline `onclick`.
The bridge also keeps a short same-prompt dedupe window in `sendPrompt()` as a safety net, but the preferred fix is still to avoid mixed ownership unless you opt in deliberately.

View File

@@ -0,0 +1,23 @@
# RichUI Default Action Opt-Out
> Discovered: 2026-03-16
## Context
This applies to RichUI embeds generated by `plugins/pipes/github-copilot-sdk/github_copilot_sdk.py`, especially when a specific embed should render state without fallback prompt or link actions.
## Finding
The RichUI bridge can add fallback action buttons based on declarative prompt/link metadata. Static embeds can explicitly opt out when their HTML includes `data-openwebui-no-default-actions="1"` or `data-openwebui-static-widget="1"`.
## Solution / Pattern
Mark the embed root with both attributes and keep the embed wrapped through `_prepare_richui_embed_html(...)` when you explicitly want to suppress fallback actions.
Example:
```html
<div class="w" data-openwebui-no-default-actions="1" data-openwebui-static-widget="1">
```
## Gotchas
If the opt-out markers are missing, RichUI fallback actions can reappear even after interactive row handlers have been removed from the widget itself.
This opt-out only suppresses fallback prompt/link injection. It does not affect the SQL-driven TODO refresh path, which still re-emits the widget through `type: embeds` after `todos` or `todo_deps` updates.

View File

@@ -0,0 +1,89 @@
# RichUI Interaction API
> Discovered: 2026-03-16
## Context
This applies to RichUI HTML embeds generated by `plugins/pipes/github-copilot-sdk/github_copilot_sdk.py` when the page needs to talk back to the OpenWebUI chat UI.
## Finding
The most reliable design is a small recommended interaction surface with only four primary actions:
1. continue chat now
2. prefill chat input without sending
3. submit the current chat input
4. open an external link
Keeping the recommended API this small reduces LLM choice overload and makes multilingual HTML generation more consistent.
Advanced capabilities still exist, but they are intentionally treated as opt-in patterns rather than the default contract:
- copy text to clipboard
- structured selection state
- template-based prompt/copy actions driven by current selections
## Solution / Pattern
Prefer declarative attributes first:
```html
<!-- 1. Continue chat immediately -->
<button data-openwebui-prompt="Explain this workflow step by step">Explain</button>
<!-- 2. Prefill the chat input only -->
<button
data-openwebui-prompt="Draft a rollout checklist for this design"
data-openwebui-action="fill"
>
Draft in input
</button>
<!-- 3. Submit the current chat input -->
<button data-openwebui-action="submit">Send current draft</button>
<!-- 4. Open a real URL -->
<a data-openwebui-link="https://docs.example.com">Docs</a>
```
When JavaScript is genuinely needed, prefer the object methods:
```javascript
window.OpenWebUIBridge.prompt(text);
window.OpenWebUIBridge.fill(text);
window.OpenWebUIBridge.submit();
window.OpenWebUIBridge.openLink(url);
window.OpenWebUIBridge.reportHeight();
```
Use advanced patterns only when the page genuinely needs them:
```html
<!-- Copy -->
<button data-openwebui-copy="npm run build && npm test">Copy command</button>
<!-- Pick a structured selection -->
<button data-openwebui-select="role" data-openwebui-value="reviewer">
Reviewer
</button>
<!-- Use the current selection in a follow-up action -->
<button data-openwebui-prompt-template="Explain the responsibilities of {{role}}">
Explain selected role
</button>
```
### Quick decision guide
- Need an immediate answer now → `data-openwebui-prompt`
- Need the user to review/edit first → `data-openwebui-action="fill"`
- Need to send what is already in chat input → `data-openwebui-action="submit"`
- Need to open an external resource → `data-openwebui-link`
- Need copy UX → `data-openwebui-copy`
- Need pick-then-act UX → `data-openwebui-select` + template placeholder
For most pages, keep to one dominant interaction style and only 2-4 visible actions.
## Gotchas
Inline `onclick` owns click behavior by default. If an element mixes inline click code with declarative prompt/link attributes, declarative handling is skipped unless `data-openwebui-force-declarative="1"` is present.
Legacy aliases such as `sendPrompt(...)` still work for compatibility, but new generated pages should prefer the smaller object-method API or the declarative contract above.
The bridge still keeps a short same-prompt dedupe window as a safety net, but the preferred design is to avoid mixed ownership in the first place.