fix(validation): cap documents-with-memories limit and bulk-delete containerTags - #1584
Open
Sravanjangam wants to merge 1 commit into
Open
fix(validation): cap documents-with-memories limit and bulk-delete containerTags#1584Sravanjangam wants to merge 1 commit into
Sravanjangam wants to merge 1 commit into
Conversation
…containerTags - DocumentsWithMemoriesQuerySchema.limit gains .max(100), matching the cap style of every sibling list schema (SearchRequest <= 100, ListMemories <= 1100). The omission was unguarded: each row expands joined memory entries, so an arbitrary limit was a memory/CPU/cost amplifier. Cap test added, mirroring the existing ListMemories cap test. - BulkDeleteMemoriesSchema.containerTags now caps at 100 tags of <=256 chars, aligning the most destructive operation in the schema with the hard .max(100) already applied to its ids array.
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
1 participant
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.
Hi supermemory team 👋 Thanks for building such a great product! While running a security & quality audit of the repo we hit this issue and put together a small, tested fix — details below.
Problem
Two schemas in
packages/validationmissed bounds their whole schema family applies:DocumentsWithMemoriesQuerySchema.limithad no.max()while sibling query schemas cap at 100 → unbounded row-join amplification on documents-with-memories queries.BulkDeleteMemoriesSchema.containerTagsaccepted unlimited entries of unlimited length while the parallelidsfield was capped.max(100)→ destructive fan-out asymmetry.Part of #1578 (finding M9).
Solution
Align with the family's existing convention (
.max(100)) rather than inventing new limits — minimal diff, consistent developer experience.Changes
packages/validation/src/api.ts→DocumentsWithMemoriesQuerySchema.limitgains.max(100)BulkDeleteMemoriesSchema.containerTagsgains.max(100)items, each ≤256 charsVerification
Fresh from the committed branch:
bun test api.test.ts→ 29 pass;bunx tsc --noEmit→ exit 0; Biome clean.Happy to iterate on any of this — feedback and reworks very welcome! 🙏
Environment
fix/validation-limit-caps— all gates re-run fresh at commitf13df7a14530