Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,584 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c
Lĩnh vực
backend, operating-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C
Star
45.8k
Fork
3.8k
Merge trung bình
3 ngày 4 giờ
Pull request đã merge (30 ngày)
208

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của DeusData/codebase-memory-mcp

Tất cả issue của DeusData/codebase-memory-mcp

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.