[robelest]

Closes #361.

getFilesToDelete and deleteFiles take an optional lastTouchedBefore (ms since epoch) in place of the fixed Date.now() - 24h. Passing the same cutoff to both keeps any file used at or after it, and files with a reference are always kept. NaN and future cutoffs are rejected, since a future one would delete a file reused between listing and deleting. force is unchanged.

Only for resets: files from before the cutoff that aren't in a saved message yet (uploads, or a running generation's files) are deleted too, since the grace period is what reserves them until then.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@convex-dev/agent@437

commit: 5e36f03

[robelest]

@ianmacartney want your read on direction here. The 24-hour grace period is the only thing reserving a file between storeFile and the message that references it (useExistingFile bumps lastTouchedAt without adding a reference). I tried three shapes:

• ignoreGracePeriod: boolean: deletes anything unreferenced, including files reused between listing and deleting.
• deleteFiles({ files }) with the listed docs, deleting only ones unchanged since: deleteFiles gets a second input form, and same-millisecond reuse slips past it.
• lastTouchedBefore: number, one cutoff passed to both, which is what this PR now does: the cleanest code (it just replaces Date.now() - FILE_CLEANUP_GRACE_MS), and it keeps files touched after listing, but it's an untyped epoch-ms number in the API.

None is safe for a file stored before the cutoff whose message isn't saved yet, so it's documented as reset-only, which is the case in #361. The root fix would be reserving the file under its pending message so cleanup needs no grace period at all.

[cubic-dev-ai]

All reported issues were addressed

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>