2025-10-21 13:10:34 -07:00
/ * *
* Integration Tests for getRelations ( ) Fix ( v4 . 1.3 )
*
* Tests for Bug : getRelations ( ) returns empty array when called without parameters
* This validates that the fix allows retrieving all relationships with proper pagination
*
* NO MOCKS - Real integration tests with actual storage
* /
import { describe , it , expect , beforeEach , afterEach } from 'vitest'
import { Brainy } from '../../src/brainy.js'
import { NounType , VerbType } from '../../src/types/graphTypes.js'
import * as fs from 'fs/promises'
describe ( 'getRelations() Fix (v4.1.3)' , ( ) = > {
let brain : Brainy
const testPath = './test-brainy-get-relations-fix'
beforeEach ( async ( ) = > {
// Clean up test directory
try {
await fs . rm ( testPath , { recursive : true , force : true } )
} catch {
// Ignore if doesn't exist
}
// Create fresh Brainy instance
brain = new Brainy ( {
storage : { type : 'filesystem' , path : testPath }
} )
await brain . init ( )
} )
afterEach ( async ( ) = > {
// Clean up test directory
try {
await fs . rm ( testPath , { recursive : true , force : true } )
} catch {
// Ignore cleanup errors
}
} )
describe ( 'Get All Relationships (No Parameters)' , ( ) = > {
it ( 'should return all relationships when called with no parameters' , async ( ) = > {
// Create entities
const person1 = await brain . add ( { data : 'Alice' , type : NounType . Person } )
const person2 = await brain . add ( { data : 'Bob' , type : NounType . Person } )
const person3 = await brain . add ( { data : 'Charlie' , type : NounType . Person } )
// Create relationships
await brain . relate ( { from : person1 , to : person2 , type : VerbType . FriendOf } )
await brain . relate ( { from : person2 , to : person3 , type : VerbType . FriendOf } )
await brain . relate ( { from : person1 , to : person3 , type : VerbType . WorksWith } )
// Flush to storage
await brain . flush ( )
// Get all relationships - THIS IS THE BUG FIX!
const relations = await brain . getRelations ( )
// Should return all 3 relationships
expect ( relations ) . toHaveLength ( 3 )
expect ( relations . every ( r = > r . id && r . from && r . to && r . type ) ) . toBe ( true )
} )
it ( 'should return empty array when no relationships exist' , async ( ) = > {
// Create entities but no relationships
await brain . add ( { data : 'Entity 1' , type : NounType . Document } )
await brain . add ( { data : 'Entity 2' , type : NounType . Document } )
await brain . flush ( )
// Get all relationships
const relations = await brain . getRelations ( )
// Should return empty array
expect ( relations ) . toHaveLength ( 0 )
} )
it ( 'should support pagination for large relationship sets' , async ( ) = > {
// Create entities
const entities = [ ]
for ( let i = 0 ; i < 10 ; i ++ ) {
entities . push ( await brain . add ( { data : ` Entity ${ i } ` , type : NounType . Document } ) )
}
// Create 20 relationships
for ( let i = 0 ; i < 10 ; i ++ ) {
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 1 ) % 10 ] ,
type : VerbType . RelatedTo
} )
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 2 ) % 10 ] ,
type : VerbType . ChildOf
} )
}
await brain . flush ( )
// Get first page (limit: 10)
const page1 = await brain . getRelations ( { limit : 10 } )
expect ( page1 ) . toHaveLength ( 10 )
// Get second page (offset: 10, limit: 10)
const page2 = await brain . getRelations ( { offset : 10 , limit : 10 } )
expect ( page2 ) . toHaveLength ( 10 )
// Ensure no duplicates between pages
const page1Ids = new Set ( page1 . map ( r = > r . id ) )
const page2Ids = new Set ( page2 . map ( r = > r . id ) )
const intersection = [ . . . page1Ids ] . filter ( id = > page2Ids . has ( id ) )
expect ( intersection ) . toHaveLength ( 0 )
} )
it ( 'should filter by type when getting all relationships' , async ( ) = > {
// Create entities
const person1 = await brain . add ( { data : 'Alice' , type : NounType . Person } )
const person2 = await brain . add ( { data : 'Bob' , type : NounType . Person } )
const person3 = await brain . add ( { data : 'Charlie' , type : NounType . Person } )
// Create different types of relationships
await brain . relate ( { from : person1 , to : person2 , type : VerbType . FriendOf } )
await brain . relate ( { from : person2 , to : person3 , type : VerbType . FriendOf } )
await brain . relate ( { from : person1 , to : person3 , type : VerbType . WorksWith } )
await brain . flush ( )
// Get only FriendOf relationships
const friendRelations = await brain . getRelations ( { type : VerbType . FriendOf } )
expect ( friendRelations ) . toHaveLength ( 2 )
expect ( friendRelations . every ( r = > r . type === VerbType . FriendOf ) ) . toBe ( true )
// Get only WorksWith relationships
const workRelations = await brain . getRelations ( { type : VerbType . WorksWith } )
expect ( workRelations ) . toHaveLength ( 1 )
expect ( workRelations [ 0 ] . type ) . toBe ( VerbType . WorksWith )
} )
it ( 'should filter by multiple types when getting all relationships' , async ( ) = > {
// Create entities
const entities = [ ]
for ( let i = 0 ; i < 5 ; i ++ ) {
entities . push ( await brain . add ( { data : ` Entity ${ i } ` , type : NounType . Person } ) )
}
// Create relationships of different types
await brain . relate ( { from : entities [ 0 ] , to : entities [ 1 ] , type : VerbType . FriendOf } )
await brain . relate ( { from : entities [ 1 ] , to : entities [ 2 ] , type : VerbType . WorksWith } )
await brain . relate ( { from : entities [ 2 ] , to : entities [ 3 ] , type : VerbType . ChildOf } )
await brain . relate ( { from : entities [ 3 ] , to : entities [ 4 ] , type : VerbType . FriendOf } )
await brain . flush ( )
// Get all relationships first to verify total count
const allRelations = await brain . getRelations ( )
expect ( allRelations ) . toHaveLength ( 4 )
// Get FriendOf and WorksWith relationships using type array filter
// NOTE: Current storage layer may not support array filters directly
// So we test each type separately and combine
const friendRelations = await brain . getRelations ( { type : VerbType . FriendOf } )
const workRelations = await brain . getRelations ( { type : VerbType . WorksWith } )
expect ( friendRelations ) . toHaveLength ( 2 )
expect ( workRelations ) . toHaveLength ( 1 )
expect ( friendRelations . every ( r = > r . type === VerbType . FriendOf ) ) . toBe ( true )
expect ( workRelations . every ( r = > r . type === VerbType . WorksWith ) ) . toBe ( true )
} )
} )
describe ( 'String ID Shorthand Syntax' , ( ) = > {
it ( 'should support string ID shorthand: getRelations(id)' , async ( ) = > {
// Create entities
const person1 = await brain . add ( { data : 'Alice' , type : NounType . Person } )
const person2 = await brain . add ( { data : 'Bob' , type : NounType . Person } )
const person3 = await brain . add ( { data : 'Charlie' , type : NounType . Person } )
// Create relationships
await brain . relate ( { from : person1 , to : person2 , type : VerbType . FriendOf } )
await brain . relate ( { from : person1 , to : person3 , type : VerbType . WorksWith } )
await brain . flush ( )
// Use string shorthand - THIS IS THE NEW SIGNATURE!
const relations = await brain . getRelations ( person1 )
// Should return both relationships from person1
expect ( relations ) . toHaveLength ( 2 )
expect ( relations . every ( r = > r . from === person1 ) ) . toBe ( true )
} )
it ( 'should be equivalent to getRelations({ from: id })' , async ( ) = > {
// Create entities and relationships
const person1 = await brain . add ( { data : 'Alice' , type : NounType . Person } )
const person2 = await brain . add ( { data : 'Bob' , type : NounType . Person } )
await brain . relate ( { from : person1 , to : person2 , type : VerbType . FriendOf } )
await brain . flush ( )
// Both syntaxes should return the same results
const shorthand = await brain . getRelations ( person1 )
const explicit = await brain . getRelations ( { from : person1 } )
expect ( shorthand ) . toEqual ( explicit )
} )
} )
describe ( 'Backward Compatibility' , ( ) = > {
it ( 'should maintain existing behavior for from parameter' , async ( ) = > {
// Create entities
const person1 = await brain . add ( { data : 'Alice' , type : NounType . Person } )
const person2 = await brain . add ( { data : 'Bob' , type : NounType . Person } )
const person3 = await brain . add ( { data : 'Charlie' , type : NounType . Person } )
// Create relationships
await brain . relate ( { from : person1 , to : person2 , type : VerbType . FriendOf } )
await brain . relate ( { from : person1 , to : person3 , type : VerbType . WorksWith } )
await brain . relate ( { from : person2 , to : person3 , type : VerbType . FriendOf } )
await brain . flush ( )
// Get relationships from person1
const relations = await brain . getRelations ( { from : person1 } )
expect ( relations ) . toHaveLength ( 2 )
expect ( relations . every ( r = > r . from === person1 ) ) . toBe ( true )
} )
it ( 'should maintain existing behavior for to parameter' , async ( ) = > {
// Create entities
const person1 = await brain . add ( { data : 'Alice' , type : NounType . Person } )
const person2 = await brain . add ( { data : 'Bob' , type : NounType . Person } )
const person3 = await brain . add ( { data : 'Charlie' , type : NounType . Person } )
// Create relationships
await brain . relate ( { from : person1 , to : person3 , type : VerbType . FriendOf } )
await brain . relate ( { from : person2 , to : person3 , type : VerbType . WorksWith } )
await brain . flush ( )
// Get relationships to person3
const relations = await brain . getRelations ( { to : person3 } )
expect ( relations ) . toHaveLength ( 2 )
expect ( relations . every ( r = > r . to === person3 ) ) . toBe ( true )
} )
it ( 'should maintain existing behavior for type filtering with from' , async ( ) = > {
// Create entities
const person1 = await brain . add ( { data : 'Alice' , type : NounType . Person } )
const person2 = await brain . add ( { data : 'Bob' , type : NounType . Person } )
const person3 = await brain . add ( { data : 'Charlie' , type : NounType . Person } )
// Create relationships
await brain . relate ( { from : person1 , to : person2 , type : VerbType . FriendOf } )
await brain . relate ( { from : person1 , to : person3 , type : VerbType . WorksWith } )
await brain . flush ( )
// Get only FriendOf relationships from person1
const relations = await brain . getRelations ( {
from : person1 ,
type : VerbType . FriendOf
} )
expect ( relations ) . toHaveLength ( 1 )
expect ( relations [ 0 ] . type ) . toBe ( VerbType . FriendOf )
} )
} )
describe ( 'Production Safety' , ( ) = > {
it ( 'should handle large relationship queries efficiently' , async ( ) = > {
// Create entities for 100 unique relationships
const entities = [ ]
for ( let i = 0 ; i < 50 ; i ++ ) {
entities . push ( await brain . add ( { data : ` Entity ${ i } ` , type : NounType . Document } ) )
}
// Create 100 unique relationships (each entity connects to 2+ others)
for ( let i = 0 ; i < 50 ; i ++ ) {
// First connection: i -> (i+1)
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 1 ) % 50 ] ,
type : VerbType . RelatedTo
} )
// Second connection: i -> (i+2) with different type to ensure uniqueness
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 2 ) % 50 ] ,
type : VerbType . ChildOf
} )
}
await brain . flush ( )
// Should handle query without issues
const startTime = Date . now ( )
const relations = await brain . getRelations ( { limit : 100 } )
const duration = Date . now ( ) - startTime
expect ( relations ) . toHaveLength ( 100 )
// Should complete reasonably fast (< 1 second)
expect ( duration ) . toBeLessThan ( 1000 )
} )
it ( 'should respect default limit of 100' , async ( ) = > {
// Create many unique relationships (more than default limit)
const entities = [ ]
for ( let i = 0 ; i < 60 ; i ++ ) {
entities . push ( await brain . add ( { data : ` Entity ${ i } ` , type : NounType . Document } ) )
}
// Create 150 unique relationships (each entity gets 2-3 connections)
for ( let i = 0 ; i < 60 ; i ++ ) {
// Connection 1: i -> (i+1)
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 1 ) % 60 ] ,
type : VerbType . RelatedTo
} )
// Connection 2: i -> (i+2) with different type
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 2 ) % 60 ] ,
type : VerbType . ChildOf
} )
// Connection 3: for first 30 entities, add third connection
if ( i < 30 ) {
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 3 ) % 60 ] ,
type : VerbType . WorksWith
} )
}
}
await brain . flush ( )
// Verify we have 150 total relationships
const allRelations = await brain . getRelations ( { limit : 200 } )
expect ( allRelations . length ) . toBe ( 150 )
// Call without limit - should default to 100
const relations = await brain . getRelations ( )
// Should return exactly 100 (default limit)
expect ( relations ) . toHaveLength ( 100 )
} )
it ( 'should support custom limits' , async ( ) = > {
// Create entities for 50 unique relationships
const entities = [ ]
for ( let i = 0 ; i < 25 ; i ++ ) {
entities . push ( await brain . add ( { data : ` Entity ${ i } ` , type : NounType . Document } ) )
}
// Create 50 unique relationships (2 per entity to different targets)
for ( let i = 0 ; i < 25 ; i ++ ) {
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 1 ) % 25 ] ,
type : VerbType . RelatedTo
} )
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 2 ) % 25 ] ,
type : VerbType . ChildOf
} )
}
await brain . flush ( )
// Verify we have 50 total
const all = await brain . getRelations ( { limit : 100 } )
expect ( all . length ) . toBe ( 50 )
// Custom limit of 25
const relations = await brain . getRelations ( { limit : 25 } )
expect ( relations ) . toHaveLength ( 25 )
} )
} )
fix: recalibrate find({ limit }) cap + two-tier enforcement + caller location
Brainy 7.30.0 introduced a memory-derived synchronous cap on `find({ limit })`
to prevent OOM. The cap was sound in intent but ~4x too conservative in
calibration: assumed 100 KB per result while typical entity footprint is 7-10 KB
(384-dim float32 vector ≈ 1.5 KB + standard fields + metadata). On a 900 MB
free-memory box the cap derived to 9000 — breaking common safety-cap patterns
like `find({ type, where, limit: 10_000 })` that typically return 10-500
entities. Surfaced as a runtime regression with cascading 500s degrading
production dashboards.
Three concurrent fixes:
A. RECALIBRATE THE FORMULA
- src/utils/paramValidation.ts:175,196,212 — the three memory-derived priorities
(reservedQueryMemory / containerMemory / freeMemory) all divided by
100 * 1024 * 1024 (100 KB per result, ~10-15x over conservative). Replaced
with a new MAX_LIMIT_KB_PER_RESULT = 25 constant that matches observed
entity size.
- Result: 4 GB container cap goes 10_000 → 40_000; 2 GB cap goes 5_000 →
20_000; 900 MB free-memory cap goes 9_000 → ~36_000. 100k hard ceiling
unchanged. `maxQueryLimit` / `reservedQueryMemory` constructor overrides
unchanged in behavior.
B. TWO-TIER ENFORCEMENT (warn-then-throw)
- Below cap (limit <= maxLimit): silent pass, unchanged.
- Soft tier (maxLimit < limit <= 2 * maxLimit): NEW — one-time warning per
call site (dedup keyed on caller stack frame + limit value), query
proceeds. Pre-7.30.2 code that relied on the cap silently allowing typical
safety-cap limits keeps working; the warning teaches the recipe so consumers
can fix it intentionally.
- Hard tier (limit > 2 * maxLimit): throw with the same teaching message
format. Real OOM territory; the cap stops being a recommendation and becomes
a guardrail.
- The 2x soft margin absorbs typical safety-cap patterns (limit: 10_000
against a 9 K-cap box) without disabling OOM protection. Real OOM territory
on a JS in-memory brain is hundreds of thousands of results, not 10x the
safety cap.
C. IMPROVED ERROR / WARNING MESSAGE
- Same shape as the 7.30.1 enforcement-error messages: state the problem,
name the three escape valves (maxQueryLimit / reservedQueryMemory /
pagination), include caller location, link to docs.
- Extracted findCallerLocation() helper from brainy.ts to a new
src/utils/callerLocation.ts so both the subtype enforcement (7.30.1) and
the limit enforcement (7.30.2) share one implementation without circular
imports.
DOCS
- New docs/guides/find-limits.md (public: true) — full reference: why the cap
exists, the four memory sources the auto-config considers, the three escape
valves with when-to-use-which guidance, and an explicit "pagination is the
future-proof pattern" callout (8.0 may tighten the cap further; pagination
keeps working unchanged).
- docs/api/README.md find() entry gets a one-paragraph `limit` tip + pointer
to the new guide.
- RELEASES.md v7.30.2 entry.
TESTS
- New tests/integration/find-limits.test.ts (9 tests): below-cap silent pass;
soft-tier warns once per call site (dedup verified by exercising same vs.
different source lines via wrapper closures); soft-tier message format
(names all three escape valves + docs link); soft-tier message includes
caller location; hard-tier throws; hard-tier message format same as
soft-tier; consumer maxQueryLimit override raises the cap and shifts both
tiers accordingly; pre-7.30.2 regression scenario explicitly covered.
- tests/unit/utils/memoryLimits.test.ts — 4 tests updated for the recalibrated
cap values (hardcoded expected numbers bumped 4x to match new 25 KB/result
assumption).
- tests/unit/utils/paramValidation.test.ts — auto-limit test extended to cover
the three-tier semantics (below-cap pass / soft-tier silent / hard-tier
throw).
- Existing suites unchanged: subtype-and-facets 26/26, verb-subtype-and-
enforcement 30/30, strict-mode-self-test 13/13. Unit 1468/1468.
CORTEX COMPATIBILITY
- Zero Cortex changes required. Every change is JS-side: formula recalibration
runs in ValidationConfig.constructor(), two-tier enforcement runs in
validateFindParams(), both fire before any storage / index / Cortex call.
- The new guide notes that Brainy 8.0's Datomic-style Db.find() may tighten
per-call limits to keep snapshot semantics cheap; pagination remains the
pattern that's guaranteed to keep working.
REPO-WIDE CLEANUP
Brainy is the only Soulcraft project that is open source. This commit also
scrubs closed-source product names and product-specific class/field references
from every tracked file in the repo (src/, docs/, tests/, RELEASES.md,
CHANGELOG.md). Consumer-reported bugs, regression scenarios, and release
notes now refer to "a consumer", "a downstream application", "a production
deployment", or "an internal report" — never to the named product. Two
product-named test files renamed to neutral diagnostic names. CLAUDE.md gains
a project-level guard rule documenting the policy and an example list of the
identifiers that may not appear in tracked code.
Verification
- npx tsc --noEmit: clean
- npm test: 1468 / 1468 unit
- All four integration subtype + verb + strict + find-limits suites: 78/78
- npm run build: clean
- Closed-source product reference audit: clean
2026-06-08 12:34:05 -07:00
describe ( 'Comparison with Internal Bug Report' , ( ) = > {
it ( 'should reproduce and fix the a consumer team bug scenario' , async ( ) = > {
2025-10-21 13:10:34 -07:00
// Reproduce the exact scenario from the bug report:
// - 524 relationships exist in GraphAdjacencyIndex
// - brain.getRelations() was returning empty array
fix: recalibrate find({ limit }) cap + two-tier enforcement + caller location
Brainy 7.30.0 introduced a memory-derived synchronous cap on `find({ limit })`
to prevent OOM. The cap was sound in intent but ~4x too conservative in
calibration: assumed 100 KB per result while typical entity footprint is 7-10 KB
(384-dim float32 vector ≈ 1.5 KB + standard fields + metadata). On a 900 MB
free-memory box the cap derived to 9000 — breaking common safety-cap patterns
like `find({ type, where, limit: 10_000 })` that typically return 10-500
entities. Surfaced as a runtime regression with cascading 500s degrading
production dashboards.
Three concurrent fixes:
A. RECALIBRATE THE FORMULA
- src/utils/paramValidation.ts:175,196,212 — the three memory-derived priorities
(reservedQueryMemory / containerMemory / freeMemory) all divided by
100 * 1024 * 1024 (100 KB per result, ~10-15x over conservative). Replaced
with a new MAX_LIMIT_KB_PER_RESULT = 25 constant that matches observed
entity size.
- Result: 4 GB container cap goes 10_000 → 40_000; 2 GB cap goes 5_000 →
20_000; 900 MB free-memory cap goes 9_000 → ~36_000. 100k hard ceiling
unchanged. `maxQueryLimit` / `reservedQueryMemory` constructor overrides
unchanged in behavior.
B. TWO-TIER ENFORCEMENT (warn-then-throw)
- Below cap (limit <= maxLimit): silent pass, unchanged.
- Soft tier (maxLimit < limit <= 2 * maxLimit): NEW — one-time warning per
call site (dedup keyed on caller stack frame + limit value), query
proceeds. Pre-7.30.2 code that relied on the cap silently allowing typical
safety-cap limits keeps working; the warning teaches the recipe so consumers
can fix it intentionally.
- Hard tier (limit > 2 * maxLimit): throw with the same teaching message
format. Real OOM territory; the cap stops being a recommendation and becomes
a guardrail.
- The 2x soft margin absorbs typical safety-cap patterns (limit: 10_000
against a 9 K-cap box) without disabling OOM protection. Real OOM territory
on a JS in-memory brain is hundreds of thousands of results, not 10x the
safety cap.
C. IMPROVED ERROR / WARNING MESSAGE
- Same shape as the 7.30.1 enforcement-error messages: state the problem,
name the three escape valves (maxQueryLimit / reservedQueryMemory /
pagination), include caller location, link to docs.
- Extracted findCallerLocation() helper from brainy.ts to a new
src/utils/callerLocation.ts so both the subtype enforcement (7.30.1) and
the limit enforcement (7.30.2) share one implementation without circular
imports.
DOCS
- New docs/guides/find-limits.md (public: true) — full reference: why the cap
exists, the four memory sources the auto-config considers, the three escape
valves with when-to-use-which guidance, and an explicit "pagination is the
future-proof pattern" callout (8.0 may tighten the cap further; pagination
keeps working unchanged).
- docs/api/README.md find() entry gets a one-paragraph `limit` tip + pointer
to the new guide.
- RELEASES.md v7.30.2 entry.
TESTS
- New tests/integration/find-limits.test.ts (9 tests): below-cap silent pass;
soft-tier warns once per call site (dedup verified by exercising same vs.
different source lines via wrapper closures); soft-tier message format
(names all three escape valves + docs link); soft-tier message includes
caller location; hard-tier throws; hard-tier message format same as
soft-tier; consumer maxQueryLimit override raises the cap and shifts both
tiers accordingly; pre-7.30.2 regression scenario explicitly covered.
- tests/unit/utils/memoryLimits.test.ts — 4 tests updated for the recalibrated
cap values (hardcoded expected numbers bumped 4x to match new 25 KB/result
assumption).
- tests/unit/utils/paramValidation.test.ts — auto-limit test extended to cover
the three-tier semantics (below-cap pass / soft-tier silent / hard-tier
throw).
- Existing suites unchanged: subtype-and-facets 26/26, verb-subtype-and-
enforcement 30/30, strict-mode-self-test 13/13. Unit 1468/1468.
CORTEX COMPATIBILITY
- Zero Cortex changes required. Every change is JS-side: formula recalibration
runs in ValidationConfig.constructor(), two-tier enforcement runs in
validateFindParams(), both fire before any storage / index / Cortex call.
- The new guide notes that Brainy 8.0's Datomic-style Db.find() may tighten
per-call limits to keep snapshot semantics cheap; pagination remains the
pattern that's guaranteed to keep working.
REPO-WIDE CLEANUP
Brainy is the only Soulcraft project that is open source. This commit also
scrubs closed-source product names and product-specific class/field references
from every tracked file in the repo (src/, docs/, tests/, RELEASES.md,
CHANGELOG.md). Consumer-reported bugs, regression scenarios, and release
notes now refer to "a consumer", "a downstream application", "a production
deployment", or "an internal report" — never to the named product. Two
product-named test files renamed to neutral diagnostic names. CLAUDE.md gains
a project-level guard rule documenting the policy and an example list of the
identifiers that may not appear in tracked code.
Verification
- npx tsc --noEmit: clean
- npm test: 1468 / 1468 unit
- All four integration subtype + verb + strict + find-limits suites: 78/78
- npm run build: clean
- Closed-source product reference audit: clean
2026-06-08 12:34:05 -07:00
// Create entities similar to Consumer import
2025-10-21 13:10:34 -07:00
const entities = [ ]
for ( let i = 0 ; i < 50 ; i ++ ) {
entities . push ( await brain . add ( {
fix: recalibrate find({ limit }) cap + two-tier enforcement + caller location
Brainy 7.30.0 introduced a memory-derived synchronous cap on `find({ limit })`
to prevent OOM. The cap was sound in intent but ~4x too conservative in
calibration: assumed 100 KB per result while typical entity footprint is 7-10 KB
(384-dim float32 vector ≈ 1.5 KB + standard fields + metadata). On a 900 MB
free-memory box the cap derived to 9000 — breaking common safety-cap patterns
like `find({ type, where, limit: 10_000 })` that typically return 10-500
entities. Surfaced as a runtime regression with cascading 500s degrading
production dashboards.
Three concurrent fixes:
A. RECALIBRATE THE FORMULA
- src/utils/paramValidation.ts:175,196,212 — the three memory-derived priorities
(reservedQueryMemory / containerMemory / freeMemory) all divided by
100 * 1024 * 1024 (100 KB per result, ~10-15x over conservative). Replaced
with a new MAX_LIMIT_KB_PER_RESULT = 25 constant that matches observed
entity size.
- Result: 4 GB container cap goes 10_000 → 40_000; 2 GB cap goes 5_000 →
20_000; 900 MB free-memory cap goes 9_000 → ~36_000. 100k hard ceiling
unchanged. `maxQueryLimit` / `reservedQueryMemory` constructor overrides
unchanged in behavior.
B. TWO-TIER ENFORCEMENT (warn-then-throw)
- Below cap (limit <= maxLimit): silent pass, unchanged.
- Soft tier (maxLimit < limit <= 2 * maxLimit): NEW — one-time warning per
call site (dedup keyed on caller stack frame + limit value), query
proceeds. Pre-7.30.2 code that relied on the cap silently allowing typical
safety-cap limits keeps working; the warning teaches the recipe so consumers
can fix it intentionally.
- Hard tier (limit > 2 * maxLimit): throw with the same teaching message
format. Real OOM territory; the cap stops being a recommendation and becomes
a guardrail.
- The 2x soft margin absorbs typical safety-cap patterns (limit: 10_000
against a 9 K-cap box) without disabling OOM protection. Real OOM territory
on a JS in-memory brain is hundreds of thousands of results, not 10x the
safety cap.
C. IMPROVED ERROR / WARNING MESSAGE
- Same shape as the 7.30.1 enforcement-error messages: state the problem,
name the three escape valves (maxQueryLimit / reservedQueryMemory /
pagination), include caller location, link to docs.
- Extracted findCallerLocation() helper from brainy.ts to a new
src/utils/callerLocation.ts so both the subtype enforcement (7.30.1) and
the limit enforcement (7.30.2) share one implementation without circular
imports.
DOCS
- New docs/guides/find-limits.md (public: true) — full reference: why the cap
exists, the four memory sources the auto-config considers, the three escape
valves with when-to-use-which guidance, and an explicit "pagination is the
future-proof pattern" callout (8.0 may tighten the cap further; pagination
keeps working unchanged).
- docs/api/README.md find() entry gets a one-paragraph `limit` tip + pointer
to the new guide.
- RELEASES.md v7.30.2 entry.
TESTS
- New tests/integration/find-limits.test.ts (9 tests): below-cap silent pass;
soft-tier warns once per call site (dedup verified by exercising same vs.
different source lines via wrapper closures); soft-tier message format
(names all three escape valves + docs link); soft-tier message includes
caller location; hard-tier throws; hard-tier message format same as
soft-tier; consumer maxQueryLimit override raises the cap and shifts both
tiers accordingly; pre-7.30.2 regression scenario explicitly covered.
- tests/unit/utils/memoryLimits.test.ts — 4 tests updated for the recalibrated
cap values (hardcoded expected numbers bumped 4x to match new 25 KB/result
assumption).
- tests/unit/utils/paramValidation.test.ts — auto-limit test extended to cover
the three-tier semantics (below-cap pass / soft-tier silent / hard-tier
throw).
- Existing suites unchanged: subtype-and-facets 26/26, verb-subtype-and-
enforcement 30/30, strict-mode-self-test 13/13. Unit 1468/1468.
CORTEX COMPATIBILITY
- Zero Cortex changes required. Every change is JS-side: formula recalibration
runs in ValidationConfig.constructor(), two-tier enforcement runs in
validateFindParams(), both fire before any storage / index / Cortex call.
- The new guide notes that Brainy 8.0's Datomic-style Db.find() may tighten
per-call limits to keep snapshot semantics cheap; pagination remains the
pattern that's guaranteed to keep working.
REPO-WIDE CLEANUP
Brainy is the only Soulcraft project that is open source. This commit also
scrubs closed-source product names and product-specific class/field references
from every tracked file in the repo (src/, docs/, tests/, RELEASES.md,
CHANGELOG.md). Consumer-reported bugs, regression scenarios, and release
notes now refer to "a consumer", "a downstream application", "a production
deployment", or "an internal report" — never to the named product. Two
product-named test files renamed to neutral diagnostic names. CLAUDE.md gains
a project-level guard rule documenting the policy and an example list of the
identifiers that may not appear in tracked code.
Verification
- npx tsc --noEmit: clean
- npm test: 1468 / 1468 unit
- All four integration subtype + verb + strict + find-limits suites: 78/78
- npm run build: clean
- Closed-source product reference audit: clean
2026-06-08 12:34:05 -07:00
data : ` Consumer Entity ${ i } ` ,
2025-10-21 13:10:34 -07:00
type : NounType . Document
} ) )
}
// Create multiple relationships (simulating import)
for ( let i = 0 ; i < 50 ; i ++ ) {
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 1 ) % 50 ] ,
type : VerbType . RelatedTo
} )
if ( i % 5 === 0 ) {
await brain . relate ( {
from : entities [ i ] ,
to : entities [ ( i + 3 ) % 50 ] ,
type : VerbType . ChildOf
} )
}
}
await brain . flush ( )
// BUG FIX TEST: This should now return relationships, not empty array!
const relations = await brain . getRelations ( )
// CRITICAL: Should NOT be empty
expect ( relations . length ) . toBeGreaterThan ( 0 )
// Should have at least the relationships we created
expect ( relations . length ) . toBeGreaterThanOrEqual ( 50 )
// All relations should be valid
expect ( relations . every ( r = >
r . id && r . from && r . to && r . type
) ) . toBe ( true )
} )
} )
} )