Repository navigation
Conversation
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
Server: consume multipart file content inside the fold to avoid a parser deadlock on files larger than the parser initial buffer (uploads above ~85 KB previously hung); reject oversized bodies with 413 before reading them and remove orphaned files on rejected uploads. Client: upload via XMLHttpRequest with a real progress bar (fetch has no upload progress), timeout scaled to file size, and a 2 GB per-file limit. Adds file-transfer tests, core writeStream cleanup tests, and i18n keys across all locales.
# Conflicts: # packages/app/src/components/file-tree-v2.tsx # packages/app/src/i18n/es.ts # packages/app/src/i18n/uk.ts
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
|
Hi @valyc0 — I tested this PR locally against the current I also built a small downstream prototype on top of your work for presenting generated image and PDF artifacts directly in session messages. It uses the download endpoint from this PR, keeps only file metadata in the session, and fetches the actual bytes when previewing or downloading. I preserved your original commits and authorship in my local prototype. I noticed the PR is currently no longer mergeable against the latest I don’t want to supersede or duplicate your PR. Would you prefer that I:
The prototype currently supports:
Happy to adapt the follow-up to whichever direction you and the maintainers prefer. |
|
Hi @BongHwi, Thank you very much for testing the PR locally and for building the downstream prototype on top of the upload/download foundation. I really appreciate the effort, and I'm glad the endpoints held up in a real-world scenario. I especially like the approach of keeping only file metadata in the session and fetching the actual bytes only when previewing or downloading — combined with the inline image previews, pan/pinch/mouse zoom, and native PDF preview, it sounds like a solid foundation for the artifact UI. I also appreciate you preserving the original commits and authorship. On the mergeability point, I re-checked against the latest Given that, I'd prefer option 3: land the artifact UI as a follow-up after this PR merges. Keeping the foundation PR focused makes it easier for the maintainers to review and merge, and your UI can then build cleanly on the merged endpoints. If it's convenient, you're welcome to share the compatibility patch anyway so I can verify it against the current tree — but there's no rush on my side. Thanks again for the collaboration. Happy to coordinate on the follow-up whenever the time comes. Best regards, |
|
Thanks for checking, and option 3 sounds good to me. You’re right about the mergeability distinction. I re-checked my local compatibility commit, and the issue came from applying the commits onto my prototype branch rather than from merging the current PR into dev. The commit only removes duplicate i18n entries introduced in that synthetic history, so there isn’t a generally useful patch for your branch to apply. I’ll keep the artifact work separate and wait for #39879 to land before preparing the implementation PR. In the meantime, I’ll open a focused feature issue for the artifact presentation behavior so the scope and UI direction can be discussed independently. Thanks again for coordinating and for keeping the foundation PR focused. |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
|
sorry to bother. i lost track of the progress here. Which PRs are we waiting to land before we can move on with the download functionality? |
|
Opened #60180 to track the remaining gap. Is this still something you would take? The gap is unchanged on current If the direction is acceptable, I can rebase this branch onto |
Issue for this PR
Closes #39878
Type of change
What does this PR do?
Completes the file manager in the web app by adding the three actions that were missing: upload, download and delete. The panel could already read, list and search files, but you could not add or remove files from the UI.
The actions are available consistently across the session header, file tree, search results and the file manager panel.
Server: new
fs.upload,fs.deleteandfs.downloadendpoints in theserver.fsgroup, all with server-side path containment (including symlink resolution viarealPath). The upload handler consumes the multipart file content inside the stream fold - the parser can only emit the next part once the current part's content is drained, so before this change uploads larger than the parser's initial buffer (~85 KB) would hang the request. The per-file limit is raised to 2 GB with a Content-Length guard that rejects oversized bodies with 413 before reading them, and any partial file from a rejected upload is cleaned up from disk.App: shared helper
packages/app/src/utils/file-transfer.tsfor upload/download with Basic auth; upload timeout scales with file size (60 s base + 1 s/MiB, capped at 1 h);ConfirmDialog+useConfirm()for delete confirmation; i18nsession.files.*keys added across all locales.How did you verify your code works?
dev- no conflicts.packages/appfor a pre-existing upstream reason (en.tsgained new export-session keys not yet translated in any locale -devitself fails, and the test is CI-skipped). Not introduced by this PR.Screenshots / recordings
Uploading with the progress bar:
Checklist