Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,584 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
backend, operating-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 4h
PR unite (30g)
208

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DeusData/codebase-memory-mcp

Tutte le issue di DeusData/codebase-memory-mcp

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.