billion-context 0.1.138-pr.1165.1041 → 0.1.138

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -437,19 +437,6 @@ Two lanes, same plugin (#941):
437
437
  plugin and the proxy never drift apart again (#953); profiles pinned to a
438
438
  local source are left alone. The refresh is best-effort and never fails the
439
439
  update itself.
440
- - **Known limitation under profile install — the `llm-pi-ai` transport
441
- (#1158):** providers served by dsh's `llm-pi-ai` layer (custom
442
- `llm-pi-ai.providers.*` routes) hand their own fetch implementation straight
443
- to the OpenAI SDK, so their model requests never pass through the global
444
- fetch patch this lane relies on — they bypass the proxy entirely and
445
- compression stays silently inactive for them (transports that use the plain
446
- global fetch work normally). Detection: the proxy logs a one-time
447
- `[plugin] NO MODEL REQUESTS seen for conversation …` warning when such a
448
- session's tools are called without any model request having arrived, and the
449
- tool error carries the same guidance. Fix: launch through `bili dsh` instead
450
- — the launcher's settings overlay rewrites those providers' `baseURL`s to
451
- `/bili/` URLs, routing them regardless of which fetch the transport
452
- injects.
453
440
 
454
441
  Under a `bili dsh` launch the plugin ATTACHES to the launcher's proxy (no
455
442
  second spawn). Raw upstream URLs rewrite to `<proxy>/bili/<url>` like
package/README.zh-CN.md CHANGED
@@ -228,7 +228,6 @@ curl -s http://localhost:8787/__bili/stats
228
228
  - **启动器:** `bili dsh` 经 `--patch` overlay(`~/.dsh-bili/.bili-acp.patch.yml`)注入完整原生插件 —— 每个 profile 启动即注册 bili 工具,模型请求盖 `x-bili-plugin` + dsh 会话 id(plugin 模式),`/acp` 会话绑定。同一份 patch 同时禁用 dsh 原生自动压缩(`compaction-basic` → `auto: false`);手动 `/compact` 仍可用。
229
229
  - **Profile 安装(免启动器)——统一泳道(#966):** `bili plugin install dsh` 对每个已存在的 profile 执行 `dsh plugin --profile <name> add billion-context` —— pnpm 把包装进各 profile 自己的 `node_modules`,dsh 自动挂载包内 patch 层(`dsh.bundle.patch.yml`)。装哪个源取决于 bili 自身的安装形态(#925):npm 安装传注册表名,checkout/dev 构建传绝对路径(`link:` 依赖,本地改动实时生效)。旧版受管块(`# bili begin` / `# bili end`,#966 之前的安装所写)在安装与卸载时都会被剥离 —— 用户条目与注释保留,清空的文件还原占位 `[]`。先在每个 profile 里跑过一次 dsh 让目录存在。插件加载时自拉起代理(已有健康实例则附看,不重复拉;父进程 pid 看门狗),经全局 fetch 补丁把模型流量改写为 `<proxy>/bili/<上游URL>`,原样注册清单工具,并按工具就绪门控 plugin 模式头(第一轮走 wire 模式)。退出开关:`BILI_NATIVE_DSH=0`。卸载:`bili plugin remove dsh` 或 `dsh plugin --profile <name> remove billion-context` —— 两者走同一通道。经注册表安装要求 npm 上已发布含 `dsh.bundle.patch.yml` 的版本。若 add 后 dsh 启动即报 `billion-context/dsh` 的 `ERR_MODULE_NOT_FOUND`,说明 profile 从陈旧的包元数据缓存里解析到了不含 bundle 子路径导出的旧版本(#953)——固定版本重装:`dsh plugin --profile <name> add billion-context@latest`。
230
230
  - **自动更新保持各 profile 同步:** 全局自更新完成后,bili 会扫描 `~/.dsh/profiles/*/package.json`,把注册表钉住的 `billion-context` 依赖刷新回新的全局版本 —— 加载的插件与代理从此不再漂移(#953);钉在本地源的 profile 不动。刷新是尽力而为,绝不会让更新本身失败。
231
- - **Profile 安装下的已知局限 —— `llm-pi-ai` 传输(#1158):** 由 dsh 的 `llm-pi-ai` 层服务的 provider(自定义 `llm-pi-ai.providers.*` 路由)把自己持有的 fetch 实现直接传给 OpenAI SDK,模型请求因此**从不经过**本泳道依赖的全局 fetch 补丁 —— 它们完全绕过代理,压缩对它们静默失效(用普通全局 fetch 的第三方 provider 不受影响)。检测:此类会话调用 bili 工具而从未有模型请求到达代理时,代理会打一次性 `[plugin] NO MODEL REQUESTS seen for conversation …` 告警,工具报错里也带同样指引。解法:改用 `bili dsh` 启动 —— 启动器的 settings overlay 会把那些 provider 的 `baseURL` 重写为 `/bili/` URL,无论传输层注入哪种 fetch,流量都必然过代理。
232
231
 
233
232
  `bili dsh` 启动下插件**附看**(attach)启动器的代理(不二次拉起)。裸上游 URL 与 spawn 模式一样重写为 `<proxy>/bili/<url>`(回环代理目标永不被代理 env 拦截,等于直接绕开 MITM);已经路由的 `/bili/` 前缀请求原样放行、只盖章。已知局限:手动 `/compact` 没有 dsh 侧事件钩子,其边界交给内核的自然 ingest diff(自动压缩已关,影响罕见)。
234
233
 
package/dist/index.js CHANGED
@@ -68845,8 +68845,6 @@ function pluginHeadersMatchModel(headers, bodyModel) {
68845
68845
  var MAX_PLUGIN_CONVERSATIONS = 1024;
68846
68846
  var conversations = /* @__PURE__ */ new Map();
68847
68847
  var remembered = /* @__PURE__ */ new Map();
68848
- var warnedNoModelRequests = /* @__PURE__ */ new Set();
68849
- var WARNED_NO_MODEL_REQUESTS_CAP = 4096;
68850
68848
  var conversationsFile = () => path17.join(stateDir(), "plugin-conversations.json");
68851
68849
  var conversationsSaveTimer;
68852
68850
  var conversationsDirty = false;
@@ -69231,19 +69229,11 @@ async function handlePluginTool(payload, res, deps) {
69231
69229
  }
69232
69230
  const { session, entry } = resolveConversation(conversationId2);
69233
69231
  if (!session) {
69234
- if (!entry) {
69235
- if (!warnedNoModelRequests.has(conversationId2)) {
69236
- if (warnedNoModelRequests.size >= WARNED_NO_MODEL_REQUESTS_CAP) warnedNoModelRequests.clear();
69237
- warnedNoModelRequests.add(conversationId2);
69238
- deps.log("warn", `[plugin] NO MODEL REQUESTS seen for conversation ${conversationId2} (tool "${tool}"): the model answered without any of its requests reaching this proxy \u2014 its LLM transport likely bypasses the intercepted fetch (SDK-injected fetch; known case: dsh llm-pi-ai custom providers under a bare \`dsh\` profile install \u2014 run through the \`bili dsh\` launcher, which rewrites their baseURLs) or the conversation id is stale after a host resume. Verify: send a message and look for processTurn lines in bili.log \u2014 none appearing means the transport is bypassing the proxy.`);
69239
- }
69240
- } else {
69241
- deps.log("warn", `[plugin] tool "${tool}" rejected for conversation ${conversationId2}: id registered but session not resident in this proxy instance`);
69242
- }
69232
+ deps.log("warn", `[plugin] tool "${tool}" rejected for conversation ${conversationId2}: ${entry ? "id registered but session not resident in this proxy instance" : "id never registered (stale shim session id after host resume?)"}`);
69243
69233
  res.writeHead(404, { "content-type": "application/json" });
69244
69234
  res.end(JSON.stringify({
69245
69235
  ok: false,
69246
- error: !entry ? "unknown plugin conversation (no model request has arrived with this conversation id yet \u2014 if your messages ARE still reaching the model, its LLM transport is likely bypassing this proxy's fetch interception (SDK-injected fetch; e.g. dsh llm-pi-ai under a bare profile install \u2014 run through the bili launcher) or the id is stale after a host resume; check bili.log for processTurn lines)" : "unknown plugin conversation (id registered but its session is not resident in this proxy instance \u2014 a fresh model request re-binds it)"
69236
+ error: !entry ? "unknown plugin conversation (no model request has arrived with this conversation id yet)" : "unknown plugin conversation (id registered but its session is not resident in this proxy instance \u2014 a fresh model request re-binds it)"
69247
69237
  }));
69248
69238
  return;
69249
69239
  }