Windows flake: withFileLock throws EPERM when the previous holder's lock file is still being deleted

Aperta Adatta ai principianti
#2,929 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
79/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript, node.js
Ambito
backend, testing

Direzione di ricerca

Inizia da src/core/util/file_lock.js e dall’errore di Windows descritto in test/core/action-marker-lock.test.js:344. Verifica come withFileLock gestisce gli errori di fs.open(lockPath, 'wx') e come il ciclo con scadenza esistente effettua nuovi tentativi; aggiungi test mirati iniettando il codice di errore pertinente. Il lavoro è completato quando l’errore transitorio di Windows viene ritentato e il test di contesa del lock passa.

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

Descrizione

What happened

On test-windows, test/core/action-marker-lock.test.js:344 ("concurrent removals from two processes both stick") failed because one worker exited 1:

Error: EPERM: operation not permitted, open '...\hypaware\config-control\client-actions.json.lock'
    at async withFileLock (src/core/util/file_lock.js:68:22)
  • Run 42283835049, job 128119418060 (#2928 at 44c35d11, Node 26.13.0 on windows-latest), 2026-11-06T19:55Z.
  • The PR does not touch the lock or the action markers; every other job on that head was green.

Likely cause

withFileLock creates the lock with fs.open(lockPath, 'wx') and retries only on EEXIST. On Windows, while the previous holder's fs.rm of the lock file is still pending, a create of the same name fails with EPERM (access denied on a delete-pending file) rather than EEXIST. The lock then throws instead of waiting, so the caller's operation fails.

Reach

This is not only a test problem. Every withFileLock caller can hit it on Windows under contention between two processes:

  • the client-action marker store (action_reconciler.js);
  • remote credentials (credentials.js);
  • the service token (service_token.js);
  • the grep config migration (grep_migration.js).

The failure is a spurious error before fn runs, so nothing is half-written. The operation is refused, not corrupted.

Possible fix

On win32, treat EPERM (and possibly EACCES) from the wx open like EEXIST inside the existing deadline loop. A test can inject the error code.

🤖 Generated with Claude Code

Lingua principale
JavaScript
Stelle
11
Fork
0
Merge medio
2h 15m
PR unite (30g)
322

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 hyparam/hypaware

Tutte le issue di hyparam/hypaware

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.