Malformed f32le audio buffer permanently poisons the Whisper processing queue (later valid transcribe calls fail until restart)

[ajanaku1]

Summary

A single malformed audio buffer sent to a loaded Whisper model doesn't just fail that one transcribe call. It poisons the model's processing queue so that every subsequent transcribe on the same model instance fails with the same error, until the provider process restarts.

Seen with @qvac/sdk@0.13.5 while feeding f32le audio to whisper-tiny. If the audio buffer's byte length isn't a multiple of 4 (as a valid f32le stream must be), the call fails with:

Failed to append data to processing queue, error: f32le buffer length must be a multiple of 4

That part is reasonable — the input was malformed. The problem is that the queue never recovers. A later, well-formed request on the same modelId throws the identical error, as though the bad bytes are still stuck in the queue.

Environment

• @qvac/sdk 0.13.5
• Node.js 22+ (also seen on 25)
• macOS 14 (Darwin 24.6.0)
• Model: WHISPER_TINY (registry), modelConfig.audio_format: "f32le"

Steps to reproduce

Save as repro-whisper-queue.mjs:

import { loadModel, transcribe, close, WHISPER_TINY } from "@qvac/sdk";
import { readFile } from "node:fs/promises";

const modelId = await loadModel({
  modelSrc: WHISPER_TINY,
  modelConfig: { audio_format: "f32le", strategy: "greedy", n_threads: 4, language: "en", no_timestamps: true },
});

// A valid f32le buffer (length is a multiple of 4). Use any 16kHz mono f32le clip.
const good = await readFile("./voice-note.f32le");

// 1. Corrupt request: length NOT a multiple of 4 → expected failure.
try {
  await transcribe({ modelId, audioChunk: good.subarray(0, good.length - 1) });
  console.log("unexpected: corrupt request succeeded");
} catch (e) {
  console.log("1) corrupt request failed as expected:", e.message);
}

// 2. Valid request on the SAME model → should succeed, but fails with the
//    same queue error until the process restarts.
try {
  const text = await transcribe({ modelId, audioChunk: good });
  console.log("2) valid request OK:", JSON.stringify(text.trim()));
} catch (e) {
  console.log("2) valid request FAILED (queue poisoned):", e.message);
}

void close();

To make a valid f32le clip from any audio file:

ffmpeg -i input.wav -f f32le -ar 16000 -ac 1 voice-note.f32le

Expected

The malformed request fails on its own. The next well-formed transcribe on the same model succeeds.

Actual

The malformed request poisons the queue. Every later transcribe on that modelId fails with "Failed to append data to processing queue, error: f32le buffer length must be a multiple of 4" until the provider restarts.

Suggested fix

Validate the audio-chunk length before appending to the processing queue and reject just that request, leaving the queue intact. A per-request InvalidAudioChunk-style error that doesn't wedge the model would make this fully recoverable.

Context

Found while extending QVAC delegation to transcribe (building a P2P inference marketplace). Related, separately-filed finding on the completion side: #3220.

[victorchimakanu]

The failure mode you describe means the length check and the queue append are not isolated. Once the malformed bytes hit the processing queue, nothing clears them, and the model instance stays wedged until the provider restarts. Your suggested fix is the right boundary: validate the chunk length before it is appended, fail only that request, and leave the queue intact. I am flagging it to the team as filed, together with #3220.

Until that lands, the practical guard is to validate before calling transcribe. For f32le audio, reject any buffer whose byte length is not a multiple of 4 before it reaches the model. In a delegation setup that check belongs on the provider node as well, so one malformed request from a client cannot wedge the shared Whisper instance for every other client.

One ask. Retest on @qvac/sdk 0.14.1 and attach the log if it still reproduces. The report is on 0.13.5 and a current version confirmation makes the fix easier to place.

[ajanaku1]

Retested on 0.14.1: still reproduces, identical signature. Fresh install, self-contained repro (generates a sine clip, no audio file needed):

1. valid audio : ok ( You)
2. malformed    : error (Failed to append data to processing queue, error: f32le buffer length must be a multiple of 4)
3. valid again  : error (Failed to append data to processing queue, error: f32le buffer length must be a multiple of 4)

Logs for both versions plus the repro script:
https://github.com/ajanaku1/InferMart/blob/main/docs/upstream/retest-0.14.1/whisper-poison-0141.log
https://github.com/ajanaku1/InferMart/blob/main/docs/upstream/retest-0.14.1/whisper-poison-0135-vanilla.log
https://github.com/ajanaku1/InferMart/blob/main/docs/upstream/repro-whisper-queue-poison.mjs

One scoping detail that may help place the fix: the poisoning only triggers when audio_format: "f32le" is set in the loadModel modelConfig. Passing the format per transcribe call instead goes through a path that silently tolerates a truncated buffer on both 0.13.5 and 0.14.1, which is its own small surprise, but the queue survives.

We also shipped the provider-side guard you suggested: the provider rejects any buffer that is not a whole number of 32-bit samples before it reaches the model, so one malformed request fails alone and the shared instance stays healthy for other clients. Implementation, if useful as a reference: https://github.com/ajanaku1/InferMart/blob/main/packages/shared/audio-guard.js

[victorchimakanu]

Confirmed on 0.14.1 as well. The validation fix has not landed yet. The queue-poisoning behavior is flagged to the team; I will update here when a fix is in flight.

[costin-busioc]

@ajanaku1 thank you for the detailed replies and all the contributions here, really appreciated!

Apologies for the back and forth, but 0.15 is our latest line now. No promises it touches this one directly, but since it's the current latest, would you be able to confirm whether this still reproduces on 0.15? That would help us isolate a potential fix closer to where the code sits today.

Thanks in advance!

[ajanaku1]

@costin-busioc — ran the repro on 0.15.0, same result. queue's still poisoned

One thing worth flagging: 0.15.0 won't install with a clean npm install. Four of its deps aren't on the registry:

@qvac/decoder-audio (wants ^0.5.0)
@qvac/transcription-whispercpp (wants ^0.11.1)
@qvac/tts-ggml (wants ^0.4.2)
@qvac/vla-ggml (wants ^0.11.2)

All 404. 0.14.1 declared the same packages at slightly lower ranges, and they were publishable when I ran that retest, so they seem to have been pulled since. I only got 0.15.0 to install by adding npm overrides that pinned every @qvac/* dep to whatever was still sitting in node_modules from the 0.14.1 install. For the four missing ones, that meant:

decoder-audio: 0.5.0 on disk, wants ^0.5.0 (this one matched)
transcription-whispercpp: 0.9.1 on disk, wants ^0.11.1
tts-ggml: 0.2.4 on disk, wants ^0.4.2
vla-ggml: 0.3.2 on disk, wants ^0.11.2

Not ideal, but it was enough to confirm the bug's still there. Happy to retest on a clean install once the dependencies are back on npm.

[victorchimakanu]

Confirmed the queue fix was not part of the 0.15.0 release, so the repro is expected — still tracked on the team side.

On the missing packages: those four @qvac/* deps look like they hit npm after a short delay at the point of the 0.15.0 release. They are all available now — decoder-audio 0.5.0, transcription-whispercpp 0.12.0, tts-ggml 0.5.0, vla-ggml 0.12.0 — so a clean npm install @qvac/sdk@0.15.0 should resolve without overrides. Worth testing from a fresh install when you get a chance to establish a clean baseline.