Accept companion audio/x-m4a uploads (unblock desktop recording storage)#157
Merged
Conversation
supabase-swift derives the upload content type from the .m4a file extension as audio/x-m4a, overriding the explicit audio/mp4, so every companion segment and recording was rejected 415 by the bucket allow-list and no audio ever reached storage. Admit audio/x-m4a and audio/aac (the essences a Mac produces); browser webm uploads are unaffected. Caught by a live desktop recording, not reachable by any Swift unit test.
c361c1e to
31b8479
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Live desktop recording revealed the meeting-audio bucket rejected every companion upload with 415
mime type audio/x-m4a is not supported. supabase-swift sets the multipart content type from the .m4a extension (audio/x-m4a), overriding the explicit audio/mp4 the client passes, and the bucket allow-list only had bare containers. Migration admits audio/x-m4a + audio/aac. No Swift unit test hits real storage, so only an end-to-end recording surfaced this. Contract test added in verify-audio-capture. NOTE: a companion-side UUID-case fix (storage path used uppercase UUID -> RLS denial) ships separately in minutia-desktop; both are required for companion audio to land.