fix(frontend): A finished upload confirms itself instead of vanishing - #5793
Closed
ardaerzin wants to merge 1 commit into
Closed
fix(frontend): A finished upload confirms itself instead of vanishing#5793ardaerzin wants to merge 1 commit into
ardaerzin wants to merge 1 commit into
Conversation
An upload's optimistic tile is dropped the moment the write lands, and the real file takes its place from the refetched listing — unless a drive filter hides it (a dotfile with hidden files off, or a git-ignored .env). The tile then blinked out into nothing, which reads as a failed upload, and nothing else confirmed the write: the drive only toasted for downloads. Every completed batch now toasts, and whatever the filters would have swallowed is revealed. Hidden-ness is decidable from the path, so it flips before the toast. Git-ignored-ness is not — the listing simply omits the entry — so the file is confirmed against the refetched directory, and one still missing from a settled listing flips the git-ignored toggle, with the toast saying why the view changed. The settle rule is pure and tested: it only rules once the destination directory is loaded and no longer fetching, either from observing the invalidation's own refetch or after a 1.5s floor when that refetch was too quick to see. A directory that never loads ages out and is dropped without touching a filter.
dosubot
Bot
added
size:L
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughSummary by CodeRabbit
WalkthroughUpload completion paths now flow from ChangesDrive upload reveal flow
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
Sequence Diagram(s)sequenceDiagram
participant DriveExplorer
participant useDriveUploads
participant useMountUpload
participant useUploadReveal
DriveExplorer->>useUploadReveal: obtain upload completion callback
DriveExplorer->>useDriveUploads: pass callback
useDriveUploads->>useMountUpload: configure callback
useMountUpload->>useUploadReveal: report completed path
useUploadReveal->>DriveExplorer: update visibility filters
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
web/oss/src/components/Drives/useUploadReveal.ts (1)
1-12: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReduce the file-level comment.
Lines 1-12 include product history and UI rationale. Keep only a short comment for the listing-settle constraint. Keep release context in the PR description.
As per coding guidelines, “Keep in-code comments to at most one short line; use longer comments only for genuinely surprising constraints such as bugs, races, or ordering requirements.”
Source: Coding guidelines
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 4b561530-939a-4f44-85c8-7c34a963b6a8
📒 Files selected for processing (5)
web/oss/src/components/Drives/DriveExplorer.tsxweb/oss/src/components/Drives/useDriveUploads.tsweb/oss/src/components/Drives/useMountUpload.tsweb/oss/src/components/Drives/useUploadReveal.test.tsweb/oss/src/components/Drives/useUploadReveal.ts
mmabrouk
approved these changes
Aug 9, 2026
Member
|
Landed in |
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
2 participants
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.
Context
Uploading a file into an agent's drive can look like it failed. The optimistic tile shows progress, then disappears the moment the write lands, and the real file takes its place from the refetched listing. When a drive filter hides that file, nothing takes its place. The tile just blinks out into an empty grid.
Two filters do this. Hidden files (any dot-prefixed path) when the eye toggle is off, and git-ignored files, which are off by default. An
.envdropped into a cloned repo hits both, since the root.gitignorecarries**/*.env*. Nothing else confirmed the write either: the drive only toasted for downloads, never for uploads.Changes
Every completed upload now toasts, and anything the filters would have swallowed reveals itself instead of vanishing.
Hidden-ness is decidable from the path, so
showHiddenflips before the toast fires and the message explains the change:Uploaded .env.ee.dev · showing hidden files.Git-ignored-ness is not decidable on the client. The listing simply omits the entry, so absence is the only available signal. The new
useUploadRevealhook watches each completed batch against the refetched directory. A file still missing from a settled listing flips the git-ignored toggle, and the toast updates to· showing git-ignored files.Uploads that finish within 300ms of each other toast as one message, so dropping a folder gives you one line instead of one per file.
The settle rule is the subtle part, so it lives in a pure function (
ruleOnBatch) rather than buried in an effect. It rules on a batch only once every destination directory is loaded and no longer fetching. It gets there either by observing the refetch that the upload's own cache invalidation kicks off, or after a 1.5s floor when that refetch was too quick to observe. A directory that never loads (an upload into a collapsed folder, say) ages out at 6s and is dropped without a verdict, so a filter never flips on a guess.Tests
ruleOnBatchcovering confirm, wait, the settle floor, the observed refetch, give-up, and a root-level upload.tsc --noEmitand eslint are clean on the touched files.What to QA
.envfile into a folder inside it. You get an "Uploaded ... showing git-ignored files" toast, the git-ignored toggle (the dashed-file icon) turns on, and the file stays visible where the progress tile was.