xxh32 leaves open handle
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- nodejs, rust, typescript
- Ambito
- backend, testing-qa
Direzione di ricerca
Inizia dal percorso di importazione in index.js alla riga 64 e riproduci il problema da test/foo.spec.ts usando l'opzione --detectOpenHandles di Jest. Traccia quale risorsa rimane aperta dopo il completamento di xxh32('foobarbaz'), quindi conferma che il processo di test termina senza l'handle segnalato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Hi, xxh32 (not sure if specifically this function or the lib in general) seems to be leaking some resources. When used as part of jest tests, it randomly causes:
"Jest did not exit one second after the test run has completed."
When executed with --detectOpenHandles:
Jest has detected the following 1 open handle potentially keeping Jest from exiting:
> 1 | import { xxh32 } from '@node-rs/xxhash';
| ^
2 | xxh32('foobarbaz');
3 |
at Runtime._loadModule (../../node_modules/jest-runtime/build/index.js:1218:29)
at Object.<anonymous> (../../node_modules/@node-rs/xxhash/index.js:64:29)
at Object.<anonymous> (test/foo.spec.ts:1:1)
This issue was originally reported as part of @nestjs repo:
https://github.com/nestjs/nest/issues/11072
While at it, hope it's ok if I mention another issue that prevents adoption by the same lib, which deals with cross-platform development: https://github.com/nestjs/nest/issues/11071
Could you perhaps clarify if this is expected behavior? Is the generated lockfile platform specific? Is this workflow possible/supported? What would be the correct/intended way to handle such situation? Thank you.
- Lingua principale
- Rust
- Stelle
- 1.5k
- Fork
- 52
- Merge medio
- 1g 2h
- PR unite (30g)
- 14
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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di napi-rs/node-rs
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
napi-rs/node-rs#1009 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
[node-rs/jieba, lunr.zh error] top-level await is not available in the configured target environmentAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di napi-rs/node-rs
Issue simili
-
comp-formats
Difficoltà 2/5 Mezza giornata Idoneità per principianti 64/100
ClickHouse/ClickHouse#131694 ·
I maintainer di solito rispondono entro 1 giorno
-
cli: `execCargoMetadata` decodes stdout per chunk, corrupting non-ASCII paths across pipe boundariesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Copperpour/Copperpour#500 ·
I maintainer di solito rispondono entro 1 giorno
-
state:triage-needed
Difficoltà 1/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno