fix(compact): prevent exponential block blowup in compact mode#2
Merged
skridlevsky merged 1 commit intoMar 5, 2026
Conversation
The compact mode in GetPage was causing a ~32x block count explosion (e.g. 1455 blocks → 47610) due to two bugs: 1. flattenCompactRecursive called enrichBlockTree(b.BlockEntity.Children) at every recursion level, re-enriching subtrees that were already fully expanded. This caused exponential re-processing of the block tree. 2. The MaxBlocks truncation was applied to enrichedBlocks before compact flattening, but flattenBlocksCompact received the raw blocks — so MaxBlocks had no effect in compact mode. Fix: Use []types.BlockEntity directly in flattenBlocksCompact/Recursive (no re-enrichment needed since compact output only needs uuid+content). Apply MaxBlocks truncation to the flat compact result instead. Verified: Projekte/Allcop (1455 blocks, 34KB markdown) now returns ~78KB with compact:true vs 10.9MB before the fix (~99% reduction). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Owner
|
Great find. That's a real bug. Merged, thank you. |
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
2 participants
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.
Problem
When calling `get_page` with `compact: true`, the response was ~32x larger than without compact mode (e.g. 1,455 blocks → 47,610 blocks, 1 MB → 10.9 MB). This defeats the purpose of compact mode entirely.
Root Cause
Two bugs in `flattenBlocksCompact` / `flattenCompactRecursive`:
Bug 1: Exponential re-enrichment
`flattenCompactRecursive` received `[]EnrichedBlock` but then called `enrichBlockTree(b.BlockEntity.Children, -1, 0)` at every recursion level. Since `BlockEntity.Children` already contains the full subtree, this re-enriched and re-flattened every subtree multiple times — causing exponential block count growth.
Bug 2: MaxBlocks had no effect in compact mode
`MaxBlocks` truncation was applied to `enrichedBlocks` before compact flattening, but `flattenBlocksCompact` received the raw `blocks` (untruncated). So `maxBlocks` was silently ignored in compact mode.
Fix
Verification
Tested on a real page (1,455 blocks, 34 KB markdown):
🤖 Generated with Claude Code