PG1204 commented on code in PR #7790:
URL: https://github.com/apache/texera/pull/7790#discussion_r3992113248
##########
frontend/src/app/workspace/component/hugging-face-audio-upload/hugging-face-audio-upload.component.ts:
##########
@@ -94,51 +67,34 @@ export class HuggingFaceAudioUploadComponent extends
FieldType<FieldTypeConfig>
input.value = "";
return;
}
- this.revokePreviewUrl();
- const previewUrl = URL.createObjectURL(file);
- this.localPreviewUrl = previewUrl;
- this.isUploading = true;
+ if (file.size > MAX_AUDIO_BYTES) {
+ this.errorMessage = "Audio file is too large (max 25 MB).";
+ input.value = "";
+ return;
+ }
Review Comment:
addressed P2 in
[32ec88e](https://github.com/apache/texera/pull/7790/commits/32ec88e7919fdefb476b60dcb7d005631cd2a8a6)
For P3, I don't think it works, because the later data:audio/ check reads
the same type the early check found empty. readAsDataURL builds the data URL's
media type from file.type, so an empty type produces data:;base64,…, which that
guard rejects anyway. The file still gets turned away, just later and with a
less accurate message ("Could not read this audio file." when reading actually
worked).
Genuinely accepting empty-MIME audio would mean loosening the pre-check, the
data:audio/ guard, and the hasAudio getter that drives the preview, plus
confirming _read_audio_input handles a non-audio/ data URL, and we'd lose the
guarantee that the stored value is audio. Happy to do it if you think it's
worth it, I just felt it's bigger than a nit. (Reasoning from the FileReader
contract, not a browser run.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
