Jekyll2026-05-30T18:05:43+08:00https://caomengxuan666.github.io/feed.xml曹梦轩记录 cxxmcp、Windows/Linux 工具、Redis 兼容数据库和一些 C++/Rust 基础设施实验。曹梦轩cxxmcp：async result 和 executor timer 这种小修最容易变成大 bug2026-05-30T00:00:00+08:002026-05-30T00:00:00+08:00https://caomengxuan666.github.io/posts/2026/05/30/cxxmcp-async-timers689581b 的提交信息很短：fix: harden async result and executor timers。这种提交通常不适合写成“发布亮点”，但适合写进开发日志。

SDK 里的 async result 和 timer 不是孤立工具。它们通常挂在请求生命周期、超时、取消、回调调度和 executor 退出路径上。一个 timer 如果在错误线程触发，或者 result 在完成/取消之间没有清晰状态，最后表现出来可能是随机 hang、重复回调、析构时崩溃，或者测试里偶现的 timeout。

cxxmcp 现在的方向是把 Peer、Service、transport 和 handler 边界拆清楚。越是这种结构，越不能让底层 timer 偷偷拥有模糊生命周期。因为上层 API 看起来越干净，底层异步边界出错时就越难解释。

这类修复我会优先关注三件事：

  1. result 是否只有一个完成路径。
  2. timer 取消和 executor shutdown 的顺序是否固定。
  3. 测试失败时有没有证据说明是超时、取消还是 handler 本身失败。

这篇先记到这里。后面如果这个区域继续改，应该把具体状态机画出来，而不是只在提交信息里写 harden。

]]>曹梦轩cxxmcp v1.1.2：release gates 先要能留下证据2026-05-30T00:00:00+08:002026-05-30T00:00:00+08:00https://caomengxuan666.github.io/posts/2026/05/30/cxxmcp-release-gates今天 cxxmcp 的提交大多不在 API 表面，而在发布链路上。

相关提交：

  • 1fdbec0：把 release gate 的 JUnit evidence 写到会被上传的路径。
  • 9949937：把 external consumer templates 放进 SDK source release。
  • 3ceaf5c：校验 split release gate archives。
  • 000430d：加 release preparation script。
  • v1.1.2：对应发布。

我现在更倾向于把 SDK 的发布看成一组可复查的证据，而不是一次打 tag。尤其是 cxxmcp 这种要给下游 CMake consumer 用的库，源码包里少一个模板、artifact 路径写错、归档层级多一层，都会变成用户侧的安装问题。

这类 CI 修复看起来琐碎，但它们决定了发布是否能被别人复现。README 里写支持 Conan、vcpkg、FetchContent 没什么用，真正要紧的是 release artifact 里有没有足够的消费样例，以及 gate 失败时能不能定位到哪个包、哪个 layout 出了问题。

后面应该继续把 release gate 的输出做得更像审计记录：版本、包内容、consumer smoke test、conformance evidence，各自有稳定路径。这样发布以后回头看，不需要靠记忆解释“当时为什么能发”。

]]>曹梦轩cxxmcp conformance 跑出来的 SEP-2243 问题2026-05-29T00:00:00+08:002026-05-29T00:00:00+08:00https://caomengxuan666.github.io/posts/2026/05/29/mcp-sep2243-conformance这次问题不是 cxxmcp 自己的单点 bug，而是 conformance、spec 和多个 SDK 之间的互操作问题。

SEP-2243 要求 MCP HTTP POST 请求带这些 header：

  • Mcp-Method：每个 POST 都要带，值来自 JSON-RPC method。
  • Mcp-Name：当请求里有 params.name 或 params.uri 时带上。

跑 cxxmcp conformance 时出现了一个矛盾：http-header-validation / ServerRejectsMissingMethodHeader 测试要求服务器拒绝缺失 Mcp-Method 的请求；但 conformance 里其他场景用的 TypeScript SDK StreamableHTTPClientTransport 本身没有发送这个 header。

所以结果会变成两难：

  • 如果服务器严格实现 SEP-2243，很多 SDK-backed 场景会失败。
  • 如果服务器为了兼容 TypeScript SDK 放宽校验，ServerRejectsMissingMethodHeader 又会失败。

我把这个问题拆成了几组 issue：

这件事对 cxxmcp 的意义是：conformance 不是“跑过就完了”。当测试、reference client 和 spec 互相打架时，SDK 要么把问题记录清楚，要么就在实现里留下一个说不清的兼容分支。

我现在更倾向于把这类问题写进 release evidence：哪些失败来自自己，哪些来自上游，哪些是 spec/SDK 之间的行为差异。否则 109/110、447/447 这种数字看起来很清楚，实际解释成本仍然很高。

]]>曹梦轩AstraDB：OBJECT、MEMORY STATS、LATENCY 这些命令不好糊弄2026-05-27T00:00:00+08:002026-05-27T00:00:00+08:00https://caomengxuan666.github.io/posts/2026/05/27/astradb-memory-latencyRedis 兼容不是只把常用读写命令跑通。客户端、监控系统和压测工具会问很多“状态类”命令，返回值不准也会造成兼容问题。

这次 AstraDB 的相关提交：

  • 9fb44c9：增强 OBJECT、MEMORY STATS 和 LATENCY。
  • 9355ae6：MEMORY STATS 使用正确的 EvictionPolicy 名称转换。

OBJECT ENCODING 这类命令看起来只是返回字符串，但它要知道底层数据结构：string 是 int 还是 raw，hash 是 hashtable，sorted set 是 b+tree，stream 是 stream。这里如果随便返回一个固定值，很多调试工具会被误导。

MEMORY STATS 更麻烦，它不能只给一个估算数字。至少要接上实际 memory tracker，还要把 maxmemory、maxmemory-policy 这类配置暴露出来。后续那个 enum 名称修复也说明了一个问题：兼容命令里的字符串就是 API，不是内部实现细节。

LATENCY 的子命令也类似。LATEST、HISTORY、RESET、EVENTS、GRAPH、DOCTOR 都会被运维脚本当作可观测性接口。实现这些命令，比补一个普通数据结构命令更能暴露系统内部是否有足够的事件记录。

]]>曹梦轩ferryllm：thinking_delta 不能被当成 text_delta2026-05-27T00:00:00+08:002026-05-27T00:00:00+08:00https://caomengxuan666.github.io/posts/2026/05/27/ferryllm-thinking-delta00cb7e5 修的是一个很典型的协议网关问题：Anthropic 后端会发 thinking_delta SSE event，但 ferryllm 的 IR 里没有对应的 ThinkingDelta variant。

结果是 adapter 把它悄悄转成了 TextDelta。这看起来像“内容还在”，但协议语义已经变了。客户端期望的是 thinking block 的增量，收到 text delta 以后可能直接认为 stream 违规，然后断开。

这次修复做了几件事：

  • 在 IR 的 ContentDelta 里加入 ThinkingDelta。
  • Anthropic adapter 把后端的 thinking delta 映射到 IR thinking delta。
  • Anthropic entry 发出正确的 thinking_delta SSE event。
  • streaming index remap 逻辑也要认识 thinking block。

ferryllm README 里写的是 Client protocol -> ferryllm IR -> provider protocol。这条路径的前提是 IR 不能丢语义。如果 IR 为了省事把不同 event 合并成普通 text，后面每个 provider/client adapter 都要靠猜来补，最后还是回到 N x M 的坑里。

所以这类 bug 的教训很直接：协议网关的中间表示宁愿多几个细粒度 variant，也不要把上游语义压扁。

]]>曹梦轩WinuxCmd v0.11.1：补 GNU coreutils 命令比想象中更像兼容性工程2026-05-27T00:00:00+08:002026-05-27T00:00:00+08:00https://caomengxuan666.github.io/posts/2026/05/27/winuxcmd-coreutils-0111WinuxCmd 的 v0.11.1 不是只加几个命令。

这轮相关提交里有三类工作：

  • a12a733：把 20 多个命令里“解析了但没真正生效”的选项接到逻辑里。
  • 4fe10c8：加 stty、dir、vdir、dircolors、chgrp。
  • 4caaf61：加 strings、hexdump、col、more。

做这类工具时，最容易低估的是“选项存在”和“行为可用”之间的差距。CLI 可以接受 --sort-keys、--strict、--one-file-system，但如果解析完没有进入输出逻辑，那它对用户来说就是假兼容。

Windows 上实现 GNU coreutils 还会遇到另一层问题：有些语义本来就不是一一对应的。比如权限、组、终端模式、设备文件、管道行为，都不能简单照搬 Unix 实现。这里更像是在做一组实用兼容层，而不是追求字面复刻。

所以我觉得 v0.11.1 的重点不是“命令数量增加到多少”，而是开始把 option wiring、测试和文档一起补齐。命令越多，越需要靠测试证明某个参数真的改变了行为。

]]>曹梦轩