xxh32 leaves open handle
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- nodejs, rust, typescript
- Área
- backend, testing-qa
Línea de trabajo
Comienza con la ruta de importación en index.js, en la línea 64, y reproduce el problema de test/foo.spec.ts usando la opción --detectOpenHandles de Jest. Rastrea qué recurso permanece abierto después de que se complete xxh32('foobarbaz') y confirma luego que el proceso de prueba termina sin el handle informado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Rust
- Estrellas
- 1.5k
- Forks
- 52
- Merge medio
- 1 d 2 h
- PR fusionados (30 d)
- 14
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de napi-rs/node-rs
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
napi-rs/node-rs#1009 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
[node-rs/jieba, lunr.zh error] top-level await is not available in the configured target environmentAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
Todos los issues de napi-rs/node-rs
Issues similares
-
comp-formats
Dificultad 2/5 Medio día Aptitud para principiantes 64/100
ClickHouse/ClickHouse#131694 ·
Los mantenedores suelen responder en 1 día
-
cli: `execCargoMetadata` decodes stdout per chunk, corrupting non-ASCII paths across pipe boundariesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Copperpour/Copperpour#500 ·
Los mantenedores suelen responder en 1 día
-
state:triage-needed
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día