Text Editing Pipeline Review

This document summarizes how text files are edited in the application and lists potential issues observed in the current implementation.

Pipeline Overview

1. Viewing a file

   • KnowledgeViewer builds a list of workBenchFiles from useSessions() and renders them through FileContent.
   • FileContent checks if the file URL is expired and, if necessary, fetches a fresh signed URL using getFabFileByIdFromServer.
   • File contents are downloaded via getContentFromFabfile which internally performs an axios.get on the signed URL.

2. Editing a file

   • When a file is opened for editing KnowledgeModal fetches the file via getFabFileByIdFromServer and loads its text using getContentFromFabfile.
   • Edits are stored in the editedContent state and saved through the handleSave method.
   • Saving either calls createFabFileOnServerWithUpload for new files or updateFileUtility for existing ones.
   • updateFileUtility sends a PUT request to /api/files/[id] with the updated metadata and fileContent.

3. Server‐side update

   • The API route (pages/api/files/[id]/index.ts) forwards the request to fabFilesService.updateFabFile using the provided body.
   • In the manager layer (server/managers/fabFileManager.ts), updateFabFile persists metadata to MongoDB and, when a filePath is supplied, uploads the new fileContent to S3:

if (updatedData.filePath && updatedFabFile.filePath === updatedData.filePath) {
  const fileKey = updatedFabFile.filePath;
  await filesStorage.upload(newContent ?? '', fileKey, {
    ContentType: updatedFabFile.mimeType,
  });
}

Potential Issues

• Missing body size limit on update API – Unlike /api/files which allows a 10 MB payload, the update route relies on Next.js defaults. Editing large files (>4 MB) will fail silently.
• File content might not reach S3 – fabFilesService.updateFabFile is invoked with the request body, but the route does not separately pass the fileContent argument required by updateFabFile in the manager. If the service does not forward fileContent, the upload step will be skipped and the old file remains in S3.
• No signed URL refresh after save – After saving, workBenchFiles still contain the previous fileUrl and fileUrlExpireAt. If the URL is cached by the browser, users may continue to read stale content until it expires or they manually refresh.
• Local state desync – KnowledgeModal updates Dexie but does not update workBenchFiles in useSessions. Views relying on that state may still show the old file metadata.
• MIME type handling – When renaming a file without an extension, the MIME type defaults to text/plain. Changing the extension does not update the MIME type, which may cause downstream processing errors.

Suggested Fixes

1. Increase body size for updates
   • Add bodyParser: { sizeLimit: '10mb' } to the config of pages/api/files/[id]/index.ts.
2. Ensure file content is uploaded
   • Verify that fabFilesService.updateFabFile forwards the fileContent argument to updateFabFile. If not, adjust the service or API route to pass it explicitly.
3. Refresh file metadata after save
   • After a successful save, re-fetch the updated file or at least update fileUrl and fileUrlExpireAt in workBenchFiles so subsequent reads use a fresh signed URL.
4. Synchronize local state
   • Update the workBenchFiles array in useSessions when handleSave completes to keep the viewer in sync.
5. Improve MIME type inference
   • When the file name changes, infer the MIME type from its extension so uploads and downloads use the correct content type.

Implementing these adjustments should improve reliability so that text edits persist consistently.