fix(decoding): raise instead of return TypeError in _get_audio_features

[subramanya-dev]

Description

In whisper/decoding.py, DecodingTask._get_audio_features() constructs a TypeError when the audio feature tensor has an unexpected dtype, but returns the exception object instead of raising it.

As a result, the caller receives a TypeError instance as audio_features and continues execution. Subsequent calls such as _detect_language() and tensor operations then fail with unrelated exceptions, making the original dtype mismatch difficult to diagnose.

Location

whisper/decoding.py

Method: DecodingTask._get_audio_features()

Current code:

if audio_features.dtype != (
    torch.float16 if self.options.fp16 else torch.float32
):
    return TypeError(
        f"audio_features has an incorrect dtype: {audio_features.dtype}"
    )

return audio_features

Expected Behavior

A dtype mismatch should immediately raise an exception and stop execution, surfacing the actual problem to the user.

Actual Behavior

The method returns a TypeError object as a normal value. Execution continues until later code attempts to use the exception object as a tensor, causing secondary failures that obscure the root cause.

Proposed Fix

if audio_features.dtype != (
    torch.float16 if self.options.fp16 else torch.float32
):
    raise TypeError(
        f"audio_features has an incorrect dtype: {audio_features.dtype}"
    )

return audio_features

Impact

• Prevents silent propagation of invalid state.
• Preserves the original error message.
• Makes debugging dtype-related issues significantly easier.
• Avoids misleading downstream crashes in language detection and decoding logic.

Additional Notes

The issue appears to be an unintended use of return TypeError(...) instead of raise TypeError(...), as the surrounding logic treats dtype mismatches as fatal validation failures.

[subramanya-dev]

Hi @jongwook and @hintz-openai,

Could you please take a look when you have a chance? This PR addresses a bug where a TypeError object is returned instead of raised, causing the original error to be masked by downstream failures.

Thank you for your time and review.

[nomiveritas]

Looks good. Replacing return TypeError(...) with raise TypeError(...) correctly preserves the original exception semantics.