Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
- Added AlertDialog UI component for user confirmation - Modified file transfer flow to request acceptance before showSaveFilePicker - Sender now waits for receiver acceptance before sending file chunks - Receiver sees dialog to accept/decline before file save picker appears - Fixes SecurityError: showSaveFilePicker must be called with user gesture Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
- Use FileMetadata type instead of any for metadata parameter - Retrieve actual peerId from transfer instead of empty string - Add transfers dependency to handleFileAck callback Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
|
@copilot Once the receiver accepts, the sender displays "File sent" with a 100% status. However, at the same time, the sender unexpectedly shows a "Receiving file" prompt and prompts the receiver again to accept the incoming file transfer. |
- Added sendFileChunks method to FileTransferManager that only sends chunks - Updated handleFileAck to use sendFileChunks instead of sendFile - Prevents metadata from being sent twice (once initially, once after acceptance) - Fixes issue where receiver was prompted to accept the same file twice Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
- Extracted sendChunks as private method to avoid code duplication - Both sendFile and sendFileChunks now use the common sendChunks method - Improves maintainability and reduces code duplication Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
Fixed in commit 50dd205. The issue was that Solution: Created a new |
|
@copilot Tested using an image, File transfer is being done, however, the image is somewhat corrupted |
- Added validation in completeTransfer to wait for all chunks to be received - Prevents premature stream closure when file-complete arrives before chunks - Includes timeout safety (30s) to prevent infinite waits - Fixes image and file corruption issues Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
- Use exponential backoff (50ms to 500ms) to reduce CPU usage - Separate timeout counters for chunk reception and buffer writing - Each phase has full 30s timeout instead of sharing one timer - More efficient polling approach for waiting on async operations Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
Fixed in commit 150deab. The corruption was caused by Solution: Added validation to wait for all chunks ( Files should now transfer completely without corruption. |
Fixed in commits a8903bd and f4c9004. Root cause: 19 chunks were stuck in the buffer because they arrived out of order. The Solution: Modified Files should now transfer correctly without corruption, even when chunks arrive out of order. |
|
@copilot [receiveChunk] Total chunks set to 171 for file 1762537341491-ftlaf9 |
- Fix bug in logging: show actual chunks written, not chunks before write - Add logging to show which chunks are missing and blocking progress - Add logging to identify gaps in chunk sequence - Add warning when closing file with unwritten chunks - Will help identify if chunks are not being sent or getting lost Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
Improved diagnostics in commit bc14c85. The logs reveal 37 chunks (indices 3, 8, 64, 65, 69...) are stuck because there are GAPS in the sequence - these chunks arrived but are waiting for missing predecessors that never came. For example, if chunk 2 never arrived, chunk 3 gets buffered forever waiting for it. This indicates chunks are being lost during transmission. Please test again and share the new console logs. They will now show:
This will confirm if chunks are not being sent, or getting lost in WebRTC transmission. |
|
@copilot 620de810f37baa41.js:11 [receiveChunk] Total chunks set to 171 for file 1762537955785-w0fop7 |
- Log when sender starts/completes sending chunks - Calculate exactly which chunks are missing (never received) - Distinguish between missing chunks vs buffered chunks - Show that buffered chunks can't be written because predecessors are missing - Will help determine if sender isn't sending all chunks or WebRTC is dropping them Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
Enhanced diagnostics in commit ba89b75. The pattern is clear: chunks are being lost during transmission. What's happening:
New logs will show:
This will confirm if WebRTC data channel is dropping chunks. Please test again and share BOTH sender and receiver console logs to see if all chunks are being sent but some are getting lost in transmission. |
|
@copilot [sendChunks] Starting to send 171 chunks for file 1762538567547-4baffo [receiveChunk] Total chunks set to 171 for file 1762538567547-4baffo |
- Log every chunk received with its index - Warn when duplicate chunks are detected - Log every chunk write operation with counter value - Will help identify if chunks are being received/written multiple times - Diagnose why receivedChunks = 172 when only 171 chunks expected Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
Critical discovery in commit c2f397b! The logs show a counter mismatch: Problem identified:
This explains the corruption - chunks 3, 8, 10, 16, 22... are stuck waiting to be written at their positions, but New detailed logging will show:
This will reveal exactly where the counter gets incremented incorrectly. Please test again and the logs will show the exact sequence of operations. |
|
@copilot [receiveChunk] Received chunk 0 for file 1762539554029-lf3sy |
Co-authored-by: jomzxc <74537369+jomzxc@users.noreply.github.com>
|
@copilot try again |
Fixed in commit bd47431. The race condition was caused by multiple concurrent calls to Root cause: Chunks 2, 5, etc. were being written twice - once by their own Solution: Added Please test the file transfer again - corruption should now be fixed! |
Fixes file transfer failures caused by SecurityError when calling
showSaveFilePicker()without a user gesture, and file corruption caused by a race condition in concurrent chunk write operations.Issues Fixed
1. SecurityError on File Reception
Problem: Receiver automatically called
showSaveFilePicker()upon receiving file metadata, violating browser security policy requiring user gestures for file system access.Solution:
AlertDialogcomponent for user confirmationshowSaveFilePicker()now called only when user clicks "Accept" (valid user gesture)2. Duplicate Metadata Transmission
Problem: Sender sent file metadata twice, causing receiver to see duplicate acceptance prompts.
Solution:
sendFileChunks()method that sends only chunks without metadata3. File Corruption from Race Condition
Problem: Multiple concurrent async calls to
writeSequentialChunks()caused chunks to be written multiple times, incrementing the counter incorrectly (e.g., 172 instead of 171), leaving some chunks stuck in the buffer and causing file corruption.Solution:
isWritinglock to prevent concurrent write operations4. Progress Display Issues
Problem: Sender showed 100% immediately after sending chunks; receiver showed 101% progress.
Solution:
transfer.totalChunksconsistently and caps at 100%Changes Made
New Components:
components/ui/alert-dialog.tsx: Radix UI-based dialog for incoming transfer requestsPendingFileTransferinterface: Queue structure for transfers awaiting user decisionCore Logic (
lib/webrtc/file-transfer.ts):sendFile()from chunk transmission logicpendingIncomingTransferstate andpendingSendsrefisWritinglock to prevent race conditions in chunk writeshandleFileMetadata()now queues transfer instead of immediately calling pickeracceptIncomingTransfer()/rejectIncomingTransfer()callbackshandleFileAck()triggers actual chunk transmission on acceptancewriteSequentialChunks()helper with concurrency protectionHook Changes (
lib/hooks/use-file-transfer.ts):File Transfer Flow
Sender:
Receiver:
Testing
Fixes #31
Original prompt
✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.