[5417] refactor(frontend): move drive mount calls onto the generated Fern client - #5519
Open
mmabrouk wants to merge 1 commit into
Open
Conversation
…ient The drive called four mount endpoints through raw axios and raw fetch, against hand-built URLs, which web/AGENTS.md rules out for frontend API code. Three of them had no choice until now: the generated client parsed the zip and file bodies as JSON and corrupted them. The previous commit fixes that at the source. Add the three calls to @agenta/entities/session, next to the mount queries that already live there: queryAgentMount, fetchMountFileBytes and exportMountFiles. They follow the same shape as their neighbours (callFern, projectScopedRequest, and zod validation on the JSON one). exportMountFiles returns the unread body so the caller still picks how to consume it. The Chromium path streams it to disk a chunk at a time, and the Safari/Firefox path buffers a blob, exactly as before. The type is restated in the package rather than re-exported from Fern, so consumers do not depend on generated types. It does not retry: the backend streams the zip member by member, so a mid-stream failure has already sent its 200 and a retry would restart a large export rather than recover it. The drive components keep only browser concerns (object URLs, the save-file picker). The hand-built Authorization header goes away with the raw fetch; the client authenticates the same way the drive's file listing already does. Refs #5417 Claude-Session: https://claude.ai/code/session_011npNAXwcM2adqdSX6QGcsz
dosubot
Bot
added
the
size:L
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughSummary by CodeRabbit
WalkthroughDrives now use shared session APIs for agent mount queries, individual file downloads, and multi-mount ZIP exports. The session package exposes these APIs and archive types, supporting both streaming-to-disk and buffered download flows. ChangesMount session API integration
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant Drives
participant SessionAPI
participant MountsClient
participant FileSystem
User->>Drives: Download mount files
Drives->>SessionAPI: exportMountFiles(mounts, projectId, filename)
SessionAPI->>MountsClient: Start ZIP export
MountsClient-->>SessionAPI: Archive stream or blob
SessionAPI-->>Drives: MountArchiveDownload
Drives->>FileSystem: Write stream or create blob URL
Possibly related PRs
🚥 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 |
dosubot
Bot
added
Frontend
refactoring
Member
Author
|
@coderabbitai review |
✅ Action performedReview finished.
|
Contributor
Railway Preview Environment
|
SamMethnani
approved these changes
Jul 25, 2026
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.
Closes #5417. Stacked on #5518 — review that one first, and merge it first. Base is
chore/mounts-binary-openapi-fern-regen, notmain, so this diff shows only its own four files.The problem
The drive reached four mount endpoints through raw axios and raw
fetchagainst hand-built URLs.web/AGENTS.mdrules that out for frontend API code, and it is the deviation #5417 was filed about.Three of the four had no alternative until now. The generated client parsed those bodies as JSON, which corrupts a zip or a file's bytes. #5518 fixes that at the source, so all four can move.
agentDrive.tsagent mount probeaxios.postto/mounts/agents/queryqueryAgentMountdriveMedia.tsfile bytesaxios.getwithresponseType: "blob"fetchMountFileBytesdriveMedia.tsdownload-all, Chromiumfetchwith a hand-built JWT headerexportMountFiles().stream()driveMedia.tsdownload-all, Safari/Firefoxaxios.postwithresponseType: "blob"exportMountFiles().blob()The change
The three Fern calls go into
@agenta/entities/session, next to the mount queries already there, and follow the same shape as their neighbours:callFern,projectScopedRequest, and zod validation on the one that returns JSON. The drive components keep only browser concerns, which is the object URLs and the save-file picker.Download behavior is unchanged.
exportMountFilesreturns the body unread, so the caller still chooses:Two deliberate details:
200; retrying would restart a potentially large export rather than recover it.On dropping the hand-built
Authorizationheader: the rawfetchattached a JWT itself. The Fern client authenticates with cookies viawithCredentials. This is not a new dependency, because the drive's own file listing already goes through the Fern client on the same endpoints. If cookie auth did not work for mounts, the drive would not list files at all today.What stays as it is
mountFileDownloadUrlstill builds a/mounts/{id}/files/downloadURL string. That is not a request our code makes; it is asrcfor a media tag so the browser streams the bytes progressively and they never enter the JS heap. There is no client call to route it through.Verification
exportMountFiles().blob(),exportMountFiles().stream()anddownloadMountFile().blob()each return the exact bytes, byte-for-byte. This is the defect the ticket describes, verified directly.fetchcall remains anywhere inweb/oss/src/components/Drives.@agenta/entitiestypechecks and lints clean; the two changedweb/ossfiles lint clean.tscoverweb/ossreports no error in any file this PR touches. The project has 587 pre-existing errors elsewhere, none of them inDrivesor the session API.Not covered
These paths are typed and compile, but I have not clicked through a download on a live stack. Both existing stacks on the dev box belong to other work, so a live run needs a stack that carries the API change from #5518. Worth a manual "download all" in both a Chromium and a Firefox profile before merge.
https://claude.ai/code/session_011npNAXwcM2adqdSX6QGcsz