[Goal] Fix missing-value parity in real Wasm rolling kernels
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- rust, typescript, wasm
- Área
- data, testing-qa
Línea de trabajo
Start by reproducing rollingMedianF64Accelerated before and after loadWasm(), then inspect the relevant Rust rolling kernels and tests under rust/ and tests/wasm/. Build with wasm-pack from rust/ and run the focused accelerated-wrapper tests plus the listed cargo, typecheck, and lint commands. Done means loaded Wasm matches fallback semantics, regression coverage passes, and candidate-head evidence is recorded.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Goal
Make all-missing rolling-window results agree between the existing TypeScript fallback and the real Rust/Wasm acceleration path, without a Wasm trap. This is a focused follow-up to #349, not a claim that the whole pandas or Wasm port is complete.
Completion Contract
- Reproduce
rollingMedianF64Accelerated(new Float64Array([NaN, 1, NaN, 3]), 1, 0)before and afterloadWasm(). The loaded implementation must return[null, 1, null, 3], not throwRuntimeError: unreachable. - Check rolling min/max for empty/all-missing windows at
minPeriods = 0, preserving current TypeScript fallback semantics including infinities. Cover positive minPeriods, mixed finite/NaN input, empty input, and representative window sizes so the fix does not only special-case the reproduction. - Add Rust regression tests and TypeScript integration tests that execute the actual accelerated wrappers with the Wasm module successfully loaded. Test the fallback in an isolated process before loading, so previous tests cannot secretly choose the backend. A missing module or early return is a failure, not passing evidence.
- Build Wasm from the candidate's Rust source; do not validate only the old checked-in binary. Keep the required generated bindings/binary consistent with source if this repository tracks them.
- Confirm candidate-head CI and the focused source-built Wasm verification pass, then reconcile published evidence in a subsequent run. Do not close the issue on a queued push, stale branch, syntax-only test, or fallback-only result.
Evidence / Verification
Record the candidate SHA and actual commands, outcomes, and assertion counts. Run cargo test --locked --manifest-path rust/Cargo.toml, wasm-pack build --target nodejs rust/ --out-dir pkg, the relevant bun test tests/wasm/ tests, affected core/window tests, bun run typecheck, and bun run lint. Report missing tooling or failing checks honestly. Link the published PR and current-head runs. A standalone Wasm Verification workflow is being installed; use it when available and do not claim its result until it completes.
Scope and Constraints
Only change the relevant Rust rolling kernels, focused tests under tests/wasm/ and Rust tests, and corresponding generated rust/pkg/ artifacts when necessary. Do not modify README, AGENTS, .autoloop/programs/, workflow policies, benchmarks, general Series/DataFrame behavior, or issue #1. Preserve existing fallback semantics; do not weaken assertions or mark cases ineligible to get a green result. One small coherent fix per commit.
Iteration Policy
First reproduce the crash and semantic mismatch, add a focused regression, fix the smallest coherent defect, and publish one canonical PR. A later run checks the real published candidate and CI evidence before accepting or completing it. If verification exposes another in-scope defect, fix it in a separate small checkpoint. Do not repeat an unchanged diagnosis or create duplicate PRs.
Blocked Stop Condition
Stop and report one actionable blocker if required tooling cannot run, the permitted scope cannot repair the behavior, branch publication fails, or evidence contradicts the claimed result. Leave the issue open and record the next required action. Never infer successful verification from unavailable results.
- Lenguaje dominante
- TypeScript
- Estrellas
- 9
- Forks
- 4
- Merge medio
- 3 d 3 h
- PR fusionados (30 d)
- 15
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
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 githubnext/tsb
-
automation ci
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
githubnext/tsb#411 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
githubnext/tsb#208 ·
-
[aw] Autoloop failed Abiertoagentic-workflows
Dificultad 4/5 3-5 días Aptitud para principiantes 40/100
githubnext/tsb#517 · 3 comentarios ·
-
[aw] Autoloop failed Abiertoagentic-workflows
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
githubnext/tsb#516 · 4 comentarios ·
-
[aw] Autoloop failed Abiertoagentic-workflows
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
githubnext/tsb#515 · 3 comentarios ·
Todos los issues de githubnext/tsb
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
bug v2
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
modelcontextprotocol/inspector#2458 · 1 comentario ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
railmapgen/rmp-gallery#4068 ·
-
Mend: dependency security vulnerability status: needs triage 🕵️♀️
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
carbon-design-system/ibm-products#9907 ·