fix(files): count the document body against the export limit

The 250 MB export cap measured only the embedded assets' declared sizes. The
markdown body was downloaded with no limit and never counted, so a large
document with modest attachments cleared the check and still produced a zip well
over the stated limit, materialized whole in memory.

The body is the largest single entry in most bundles, so excluding it left the
limit unenforced against the item most able to exceed it. It is now capped on
read and counted alongside its assets, and the message names both.

Follow-up to #5995, which introduced the asset caps without extending them to
the body.

Author: waleedlatif1

apps/sim/app/api/files/export/[id]/route.test.ts

@@ -116,6 +116,26 @@ describe('markdown export bundling', () => {
     expect(mockDownloadFile).toHaveBeenCalledTimes(1)
   })
 
+  it('counts the document body against the export limit, not just its assets', async () => {
+    // Assets alone sit under the cap; the body is what carries the bundle over it.
+    mockExtractEmbeddedImageIds.mockReturnValue(['a'])
+    mockDownloadFile.mockResolvedValue(Buffer.alloc(250 * MB))
+
+    const response = await GET(request(), context)
+
+    expect(response.status).toBe(400)
+    expect((await response.json()).error).toContain('document and its embedded files')
+  })
+
+  it('caps the document body read rather than loading it unbounded', async () => {
+    mockExtractEmbeddedImageIds.mockReturnValue([])
+
+    await GET(request(), context)
+
+    const bodyCall = mockDownloadFile.mock.calls.find(([options]) => options.key.endsWith('doc.md'))
+    expect(bodyCall?.[0].maxBytes).toBe(250 * MB)
+  })
+
   it('caps each asset download rather than trusting its declared size', async () => {
     mockExtractEmbeddedImageIds.mockReturnValue(['a'])
 

apps/sim/app/api/files/export/[id]/route.ts

@@ -128,9 +128,13 @@ export const GET = withRouteHandler(
       return NextResponse.redirect(new URL(servePath, request.url), { status: 302 })
     }
 
+    // Capped like everything else in the bundle: the document body is usually the
+    // largest single entry, so leaving it unbounded left the export limit unenforced
+    // against the one item most able to exceed it.
     const mdBuffer = await downloadFile({
       key: record.key,
       context: record.context as StorageContext,
+      maxBytes: MAX_EXPORT_TOTAL_BYTES,
     })
     let mdContent = mdBuffer.toString('utf-8')
 
@@ -180,11 +184,14 @@ export const GET = withRouteHandler(
       })
     ).filter((target): target is NonNullable<typeof target> => target !== null)
 
-    const declaredAssetBytes = assetTargets.reduce((sum, target) => sum + target.record.size, 0)
-    if (declaredAssetBytes > MAX_EXPORT_TOTAL_BYTES) {
+    // The body counts against the same budget as its assets — the zip holds both, so a
+    // limit that measured only the attachments would not describe the archive produced.
+    const bundleBytes =
+      mdBuffer.length + assetTargets.reduce((sum, target) => sum + target.record.size, 0)
+    if (bundleBytes > MAX_EXPORT_TOTAL_BYTES) {
       return NextResponse.json(
         {
-          error: `Embedded files total ${formatFileSize(declaredAssetBytes)}, which exceeds the ${formatFileSize(MAX_EXPORT_TOTAL_BYTES)} export limit.`,
+          error: `This document and its embedded files total ${formatFileSize(bundleBytes)}, which exceeds the ${formatFileSize(MAX_EXPORT_TOTAL_BYTES)} export limit.`,
         },
         { status: 400 }
       )