Stop storing raw file bytes in media.text_content
`text_content` is an extracted-text cache, but nothing stopped it from
holding a dump of bytes:
- `fileToText` ended its switch with `default: return buffer.toString("utf-8")`
and defaulted a missing extension to "txt", so any binary was decoded.
- Both extraction callers gated on `media_type == "document"`, and
`attachmentFileKind` classes everything non-image/audio/video as a
document: an SVG, a zip, a spreadsheet, a .bin.
- Nothing capped the length, so a 20 MB attachment could leave 20 MB of
text in the database.
- `storeChatAttachments` copied the text onto a second `media` row, and
`SELECT m.*` pulled the column into page props and API responses.
On a real install an SVG held 6852 characters of markup and a
`.designcraft` file held 142 KB of raw bytes.
Changes:
- `file-to-text.ts` lists the text extensions explicitly and returns
undefined for anything else; no extension is no text.
- `can-extract-text.ts` is the one allowlist (reusing
`BotTextFileExtensions`), used by both upload routes and by
`uploadAndRecordMedia`; `extension-of.ts` is shared with the storage
catalog instead of duplicated.
- `BotAttachmentTextStoreMaxChars` (200k) caps the column via
`cap-text-content.ts`.
- `store-chat-attachments.ts` no longer copies the text; ingestion
re-reads the bytes once.
- `media-columns.ts` selects every media column but `text_content`, which
now has to be asked for (`grab-messages-media`'s reply path and
ingestion do); the media CRUD routes sanitize rows they write.
- `ingest-bot-file.ts` decides on size alone, since a cached slice made
an oversized file look already read.
- `bun run media:prune-text` cleans rows that were already stored
(rerunnable, with a VACUUM hint).
Verified on the dev database: both bad rows cleared (146 KB), rerun
reports nothing to do.
This commit is contained in:
@@ -1,4 +1,3 @@
|
||||
import BunSQLite from "@moduletrace/bun-sqlite";
|
||||
import type { BUN_SQLITE_COBBLE_MEDIA } from "@/db/types/db";
|
||||
import { BotUploadFolder } from "@/src/dict/bot-file-dict";
|
||||
import enqueueFileIngest from "@/src/file-ingest/enqueue-file-ingest";
|
||||
@@ -44,6 +43,13 @@ export default async function storeChatAttachments({
|
||||
*/
|
||||
const name = safeName({ name: file.title || `file-${file.id}` });
|
||||
|
||||
/**
|
||||
* The text stays on the message's own `bot-attachment` row,
|
||||
* where a reply reads it. Copying it onto the file's row kept
|
||||
* the same text twice and left the copy behind when the
|
||||
* upload was pruned; ingestion re-reads the bytes once
|
||||
* through `extractBotFileText` instead.
|
||||
*/
|
||||
const saved = await recordBotFile({
|
||||
bot_id,
|
||||
scope: workspace_id ? "workspace" : "bot",
|
||||
@@ -57,17 +63,6 @@ export default async function storeChatAttachments({
|
||||
user_id,
|
||||
});
|
||||
|
||||
/**
|
||||
* The same text the upload already extracted, so a PDF isn't
|
||||
* unpacked a second time.
|
||||
*/
|
||||
if (file.text_content && saved.media_id) {
|
||||
await BunSQLite.sql({
|
||||
sql: `UPDATE media SET text_content = ? WHERE id = ?`,
|
||||
values: [file.text_content, saved.media_id],
|
||||
}).catch(() => {});
|
||||
}
|
||||
|
||||
await enqueueFileIngest({ file_id: saved.id! });
|
||||
} catch (error) {
|
||||
await logError({
|
||||
|
||||
Reference in New Issue
Block a user