Skip to content

fix(localapi): reject over-limit inline audio instead of silently truncating#429

Open
postoso wants to merge 1 commit into
altic-dev:mainfrom
postoso:fix/localapi-inline-audio-duration
Open

fix(localapi): reject over-limit inline audio instead of silently truncating#429
postoso wants to merge 1 commit into
altic-dev:mainfrom
postoso:fix/localapi-inline-audio-duration

Conversation

@postoso

@postoso postoso commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

What

The LocalAPI 300-second audio limit is enforced inconsistently. The file-path transcription route validates duration and returns an error, but inline/body uploads (base64 + raw POST) flow through LocalAPIAudioDecoder.samples(from:), which did min(file.length, maxFrames) and silently truncated audio past 300s. A client POSTing a 10-minute clip silently got back only the first 5 minutes transcribed.

How

samples(from:) now guards file.length <= maxFrames and throws instead of truncating, so the shared decode path (used by both inline and file-path routes) rejects over-limit audio. Extracted durationLimitExceededError() and reused it in validateDurationWithinLimit, so both routes return the byte-identical error (same HTTP 400). The under-limit path is behavior-identical.

Tests

New LocalAPIAudioDecoderTests (3 methods): inline over-limit throws, inline under-limit decodes normally, file-path over-limit throws. Synthetic silent WAV built in-memory (no ML model needed). xcodebuild test is green and swiftlint --strict is clean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant