Denoise external-module contracts are untyped any and break silently on an asset bump #26

Closed
opened 2026-09-12 02:13:11 -04:00 by jared · 0 comments
Owner

Severity: low · Type: tech-debt · Confidence: high

Location: src/lotus/lotusDenoiseProcessor.ts:341-344, 347-360

Problem

Both dynamic-import paths consume completely untyped modules: mod.createNoiseSuppressionAudioWorklet(ctx, …) as MlNode and new mod.DeepFilterNet3Core({...}) / core.createAudioWorkletNode(ctx) as AudioNode. There is no runtime shape check, and the assets are not bundled by this repo at all — cinny's vite.config.js lotusDenoise() plugin copies them from three separate upstream packages (lotusDenoiseProcessor.ts:38-43). A version bump in any of those (renamed export, changed constructor options, different assetConfig key) type-checks fine here and fails at runtime, where the only consequence is the swallowed warn from the previous finding. The same applies to the mic.getProcessor()/setProcessor LiveKit surface and mic?.sender in lotusQuality.ts:64, which rely on internals that are LocalTrack-typed only via as casts.

How to trigger

Bump deepfilternet3-noise-filter or @workadventure/noise-suppression in cinny and rebuild; denoise silently stops working with no CI signal.

Suggested fix

Declare minimal local interfaces for the two module shapes, assert the expected exports exist at runtime with a clear thrown error, and add the already-suggested integration smoke check (GET .../denoise/rnnoise.wasm == 200, plus the DFN/DTLN entry points) to CI.


Filed from the September 2026 audit (branch lotus).

**Severity:** low · **Type:** tech-debt · **Confidence:** high **Location:** `src/lotus/lotusDenoiseProcessor.ts:341-344`, `347-360` ### Problem Both dynamic-import paths consume completely untyped modules: `mod.createNoiseSuppressionAudioWorklet(ctx, …) as MlNode` and `new mod.DeepFilterNet3Core({...})` / `core.createAudioWorkletNode(ctx) as AudioNode`. There is no runtime shape check, and the assets are not bundled by this repo at all — cinny's `vite.config.js lotusDenoise()` plugin copies them from three separate upstream packages (`lotusDenoiseProcessor.ts:38-43`). A version bump in any of those (renamed export, changed constructor options, different `assetConfig` key) type-checks fine here and fails at runtime, where the only consequence is the swallowed warn from the previous finding. The same applies to the `mic.getProcessor()`/`setProcessor` LiveKit surface and `mic?.sender` in `lotusQuality.ts:64`, which rely on internals that are `LocalTrack`-typed only via `as` casts. ### How to trigger Bump `deepfilternet3-noise-filter` or `@workadventure/noise-suppression` in cinny and rebuild; denoise silently stops working with no CI signal. ### Suggested fix Declare minimal local interfaces for the two module shapes, assert the expected exports exist at runtime with a clear thrown error, and add the already-suggested integration smoke check (`GET .../denoise/rnnoise.wasm == 200`, plus the DFN/DTLN entry points) to CI. --- _Filed from the September 2026 audit (branch `lotus`)._
jared added this to the EC fork audit 2026-09 · Medium & Low milestone 2026-09-12 02:13:11 -04:00
jared added the priority: lowtech-debtarea: denoise labels 2026-09-12 02:13:11 -04:00
jared self-assigned this 2026-09-12 02:13:11 -04:00
jared closed this issue 2026-09-13 01:22:46 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: LotusGuild/element-call#26