You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit f0fd48c
Browse filesBrowse the repository at this point in the historyBrowse files
fix(knowledge): bound chunking separators so one config can't stall processing (#6735)
* fix(knowledge): bound chunking separators so one config can't stall processing
`chunkingStrategyOptionsSchema.separators` accepted an arbitrary-length array
of arbitrary-length strings, next to a `pattern` field already capped at 500
chars. `RecursiveChunker` splits the whole document once per separator and
walks the list from the top for every oversized fragment, so a persisted
config with thousands of non-matching separators cost seconds of synchronous
CPU on every later document upload — work neither the processing `Promise.race`
timeout nor the after-the-fact chunk-count cap can interrupt. Measured on a
21.3 MB document: 632 ms at 100 separators, 6.1 s at 1000, 36.8 s at 5000.
- Bound `separators` to 32 entries of at most 100 characters on the write path.
The largest built-in recipe (markdown) uses 16, so hand-tuned lists still fit.
- Keep the stored/read shape tolerant, so a config written before the bound
still lists instead of failing response validation.
- Clamp in `RecursiveChunker` too, with a warning, so an already-persisted
oversized list cannot reach the split loop. An over-long separator is dropped
rather than truncated: a truncated separator matches where the configured one
never did, silently re-cutting the document, while dropping it behaves like a
separator that finds no match. A list left empty falls back to the recipe.
- Walk non-matching separators iteratively instead of recursing, so stack depth
no longer tracks the separator count. Verified behavior-preserving against the
previous implementation over 4000 randomized configs — byte-identical output.
- Validate in the create-base modal so the limit surfaces inline.
After the fix the same 21.3 MB document costs ~300 ms at every separator count.
* fix(knowledge): gate separator validation on the recursive strategy
- The separator refines ran for every strategy, but the field only renders for
`recursive` and only that strategy submits it, so a value left behind by a
strategy switch could block submit with no visible field to clear. Gated the
same way the regex-pattern refine already is.
- Use absolute imports in the chunker test, per the repo convention.
0 commit comments