fix(qqbot): unlink temp wav on STT failure path - #23313
Conversation
07c6a0c to
5c90361
Compare
|
Quick bump on this PR. The cleanup is still current from my side and should be ready for review if it is still relevant. |
|
Following up on this one as well. The PR is still technically clean from my side: all recorded CI checks on the branch are green, it is still mergeable, and I do not see any review comments or requested changes attached to it. If the fix is still relevant, this looks like it only needs maintainer review/decision rather than more code work from me. |
|
Hi, gentle follow-up on this PR. The cleanup is still current from my side, and I would appreciate a review when convenient if it is still relevant. |
|
Merged into main via consolidated salvage PR #73515 (merge Your contribution is credited to you in git history. Thank you! Closing this PR as merged-via-salvage. |
_stt_voice_attachmentwrites the downloaded voice payload to aNamedTemporaryFile(delete=False)and then calls the configured self-hosted STT endpoint. Previously the temp WAV was unlinked only after_call_sttreturned - if it raisedhttpx.HTTPStatusError,httpx.TransportError, orIOError, the outerexceptswallowed the error but left the file behind. In a long-running bot, transient STT outages turn into a steady leak of one WAV per failed transcription in$TMPDIR.Wrap
_call_sttintry/finallysowav_pathis always unlinked, matching thesilk_pathcleanup pattern already used a few lines below in_convert_audio_to_wav_file.Test plan
Added two regression tests in
TestVoiceAttachmentTempCleanup:test_temp_wav_cleaned_up_on_stt_failure- asserts the temp file no longer exists after_call_sttraiseshttpx.HTTPStatusError. Fails on current main, passes with this patch.test_temp_wav_cleaned_up_on_stt_success- sanity check that the happy path still cleans up.Full
tests/gateway/test_qqbot.py: 144 passed, 2 unrelated failures (test_connect_uses_redirect_guard_hook,test_open_ws_honors_proxy_env) that fail on unmodified main as well due to local httpx mock setup.