Skip to content

Accept companion audio/x-m4a uploads (unblock desktop recording storage)#157

Merged
pratikbodkhe merged 1 commit into
mainfrom
fix/companion-audio-mime
Jul 4, 2026
Merged

Accept companion audio/x-m4a uploads (unblock desktop recording storage)#157
pratikbodkhe merged 1 commit into
mainfrom
fix/companion-audio-mime

Conversation

@pratikbodkhe

Copy link
Copy Markdown
Contributor

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.

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.
@pratikbodkhe pratikbodkhe force-pushed the fix/companion-audio-mime branch from c361c1e to 31b8479 Compare July 4, 2026 13:58
@pratikbodkhe pratikbodkhe merged commit cc1fa95 into main Jul 4, 2026
18 checks passed
@pratikbodkhe pratikbodkhe deleted the fix/companion-audio-mime branch July 4, 2026 14:04
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