Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Windows: index_repository fails with pipeline.stage lock_failed errno=22 on w64devkit

未关闭
  • 哪里不对？
#2,584 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
c
领域
backend, operating-systems

调研方向

Start with create_staging_path() in src/pipeline/pipeline.c, which now takes the sidecar lock before creating the stage file, and with the Windows branch of cbm_lockfile_open() in src/foundation/compat_fs.c, where _wsopen with _SH_DENYRW returns errno 22 under w64devkit. Commits 0c4831a3 and 91e31211 introduced this ordering. Done means the lock opens on the supported toolchain and a Windows regression test covers cbm_lockfile_open() and the staging path, which the maintainer has asked for, so confirm the intended primitive first.

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

描述

bug stability/performance windows

Summary

On Windows 11, a clean production build of origin/main fails index_repository before source discovery. The supervised worker exits cleanly, but the parent returns the generic Pipeline failed envelope. The worker log contains:

pipeline.stage action=lock_failed errno=22 path=...db.stage.<suffix>

The same checkout, arguments, repository path, and fresh cache/runtime succeed with the previously served binary built before the staging-lock change.

Reproduction

Environment:

  • Windows 11
  • w64devkit 2.8.0 / MinGW GCC 16.1.0
  • zlib 1.3.2
  • commit: 95c91b8d8d0fc11a01b9109b43d0eea94393f538 (current origin/main)
  • clean production binary SHA256: A113106F4DAB34D802241631970BF6D1ADB3765145E116F0696375BC75F9FD6D

Use fresh, owner-private cache and runtime directories and any local repository checkout:

$env:CBM_CACHE_DIR = 'C:\tmp\cbm-cache'
$env:CBM_RUNTIME_DIR = 'C:\tmp\cbm-runtime'
.\codebase-memory-mcp.exe cli --progress --verbose --json index_repository `
  --repo-path 'C:\src\codebase-memory-mcp' `
  --mode fast --name 'origin-main-canary' --persistence false

Expected: status=indexed.

Actual: exit code 1, isError=true, generic Pipeline failed; the worker log reports pipeline.stage action=lock_failed errno=22. The staging path code retries all generated suffixes and then gives up.

Control

The older served binary, built before the staging-lock change, indexes the exact same checkout with the exact same arguments and fresh cache/runtime:

  • SHA256: 3F935E7FEBB8AB2C4D1A9589CDD479F50B7B501A6505507CF5B5D5C09531B351
  • exit code 0
  • status=indexed
  • 22,387 nodes and 125,496 edges
  • elapsed time: approximately 8.3 seconds

This makes the failure specific to the newer runtime rather than the CLI invocation, repository contents, or cache reuse.

Source correlation

create_staging_path() in src/pipeline/pipeline.c now acquires the sidecar lock before creating the stage file. On Windows, cbm_lockfile_open() in src/foundation/compat_fs.c calls:

_wsopen(wpath,
        _O_RDWR | _O_BINARY | _O_NOINHERIT | _O_CREAT,
        _SH_DENYRW,
        _S_IREAD | _S_IWRITE);

With the supported w64devkit toolchain, this call returns -1 with errno=22 for each generated staging sidecar. Consequently, all attempts fail before the stage file becomes visible, and the worker returns the generic pipeline error.

Relevant history:

  • 0c4831a3 (fix(pipeline): own every staging file through an exclusive sidecar lock) introduced the Windows sidecar-lock primitive.
  • 91e31211 (fix(pipeline): take the stage lock before the stage file is visible) changed the ordering to lock-first. Its commit message mentions Windows red runs with errno=13; this environment reports errno=22.

The graph/index was refreshed against the current checkout before this report; the failure reproduces through the actual MCP index_repository surface as well as the CLI.

Request

Could you confirm the intended Windows lock primitive and flags for the supported w64devkit toolchain, and add a focused Windows regression test for cbm_lockfile_open() plus the index_repository staging path? It would also help if the user-facing error exposed the stage-lock errno instead of only returning Pipeline failed.

主要语言
C
星标
45.8k
派生
3.8k
平均合并
3 天 6 小时
30 天内合并 PR
201

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

DeusData/codebase-memory-mcp 的其他 Issue

查看 DeusData/codebase-memory-mcp 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

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