brainy/tests/regression/v5.7.0-deadlock.test.ts

160 lines
5 KiB
TypeScript
Raw Normal View History

fix: resolve v5.7.0 deadlock by restoring storage layer separation (v5.7.1) CRITICAL BUG FIX - v5.7.0 caused complete production failure PROBLEM: v5.7.0 introduced circular dependency deadlock during GraphAdjacencyIndex initialization: GraphAdjacencyIndex.rebuild() → storage.getVerbs() → getVerbsBySource_internal() → getGraphIndex() [NEW in v5.7.0] → [waiting for rebuild to complete] → DEADLOCK SYMPTOMS (Production Impact): - ALL imports hung at "Reading Data Structure" for 760+ seconds - brain.add() operations took 12+ seconds per entity (50x slower) - Zero entities imported successfully - 100% of Workshop users unable to import files - No errors thrown - infinite wait - Forced immediate rollback to v5.6.3 ROOT CAUSE: v5.7.0 modified storage internal methods (getVerbsBySource_internal, getVerbsByTarget_internal) to use GraphAdjacencyIndex optimization, creating tight coupling where storage depends on index AND index depends on storage. This violated separation of concerns and created deadlock. SOLUTION (Architectural Fix): Reverted storage internals to v5.6.3 implementation (lines 2320-2444): - Storage layer simple, no index dependencies ✅ - GraphAdjacencyIndex can safely call storage.getVerbs() to rebuild ✅ - No circular dependency possible ✅ - Proper layered architecture restored ✅ LAYERS (Correct Architecture): Layer 3 (Brainy/Queries): CAN use GraphAdjacencyIndex Layer 2 (GraphAdjacencyIndex): Uses storage.getVerbs() to rebuild Layer 1 (Storage Internals): NO GraphAdjacencyIndex calls IMPACT: - Slightly slower GraphAdjacencyIndex.rebuild() (one-time init cost) - High-level queries still use optimized index - Import performance unaffected (writes don't trigger init) - NO breaking changes to public API TESTING: - Added 4 regression tests (tests/regression/v5.7.0-deadlock.test.ts) - All 1146 existing tests pass ✅ - Import + relationships complete in <1 second (not 760+) - No 12+ second delays per entity ✅ FILES CHANGED: - src/storage/baseStorage.ts (reverted lines 2320-2444 to v5.6.3) - tests/regression/v5.7.0-deadlock.test.ts (new regression tests) - CHANGELOG.md (comprehensive v5.7.1 entry with upgrade instructions) VERIFICATION: Workshop team should upgrade immediately: npm install @soulcraft/brainy@5.7.1 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-11 15:24:43 -08:00
import { describe, it, expect, beforeEach } from 'vitest'
import { Brainy } from '../../src/brainy.js'
import { VerbType } from '../../src/types/graphTypes.js'
/**
* Regression test for v5.7.0 deadlock bug
*
* BUG DESCRIPTION:
* v5.7.0 introduced a circular dependency deadlock during GraphAdjacencyIndex initialization:
* - GraphAdjacencyIndex.rebuild() calls storage.getVerbs()
* - storage.getVerbsBySource_internal() calls getGraphIndex()
* - getGraphIndex() is waiting for rebuild() to complete
* - DEADLOCK: Each waits for the other
*
* SYMPTOMS:
* - ALL imports hang at "Reading Data Structure" stage
* - brain.add() operations take 12+ seconds per entity (50x slower)
* - No errors thrown - infinite wait
* - Process continues (heartbeats) but makes no progress
*
* FIX (v5.7.1):
* Reverted storage internals (getVerbsBySource_internal, getVerbsByTarget_internal)
* to v5.6.3 implementation - no getGraphIndex() calls from storage layer.
*
* TEST STRATEGY:
* 1. Create entities with relationships (triggers GraphAdjacencyIndex lazy init)
* 2. Force rebuild by accessing graph operations
* 3. Verify completes in <1 second (not 760+ seconds)
*/
describe('v5.7.0 Deadlock Regression', () => {
let brain: Brainy
beforeEach(async () => {
brain = new Brainy({ storage: { type: 'memory' } })
await brain.init()
})
it('should not deadlock during GraphAdjacencyIndex rebuild with existing verbs', async () => {
// Create 10 entities
const entities = []
for (let i = 0; i < 10; i++) {
const id = await brain.add({
data: `Entity ${i}`,
type: 'thing',
metadata: { index: i }
})
entities.push(id)
}
// Create relationships between them (triggers GraphAdjacencyIndex)
for (let i = 0; i < 9; i++) {
await brain.relate({
from: entities[i],
to: entities[i + 1],
type: VerbType.RelatedTo
})
}
// This should complete in <1 second (not hang forever)
const start = Date.now()
// Force GraphAdjacencyIndex usage by querying relationships
const relations = await brain.getRelations({ from: entities[0] })
const elapsed = Date.now() - start
// Verify no deadlock
expect(elapsed).toBeLessThan(1000)
expect(relations.length).toBeGreaterThan(0)
})
it('should handle imports without 12+ second delays per entity', async () => {
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
// Simulate import workflow (like A consumer's Excel import)
fix: resolve v5.7.0 deadlock by restoring storage layer separation (v5.7.1) CRITICAL BUG FIX - v5.7.0 caused complete production failure PROBLEM: v5.7.0 introduced circular dependency deadlock during GraphAdjacencyIndex initialization: GraphAdjacencyIndex.rebuild() → storage.getVerbs() → getVerbsBySource_internal() → getGraphIndex() [NEW in v5.7.0] → [waiting for rebuild to complete] → DEADLOCK SYMPTOMS (Production Impact): - ALL imports hung at "Reading Data Structure" for 760+ seconds - brain.add() operations took 12+ seconds per entity (50x slower) - Zero entities imported successfully - 100% of Workshop users unable to import files - No errors thrown - infinite wait - Forced immediate rollback to v5.6.3 ROOT CAUSE: v5.7.0 modified storage internal methods (getVerbsBySource_internal, getVerbsByTarget_internal) to use GraphAdjacencyIndex optimization, creating tight coupling where storage depends on index AND index depends on storage. This violated separation of concerns and created deadlock. SOLUTION (Architectural Fix): Reverted storage internals to v5.6.3 implementation (lines 2320-2444): - Storage layer simple, no index dependencies ✅ - GraphAdjacencyIndex can safely call storage.getVerbs() to rebuild ✅ - No circular dependency possible ✅ - Proper layered architecture restored ✅ LAYERS (Correct Architecture): Layer 3 (Brainy/Queries): CAN use GraphAdjacencyIndex Layer 2 (GraphAdjacencyIndex): Uses storage.getVerbs() to rebuild Layer 1 (Storage Internals): NO GraphAdjacencyIndex calls IMPACT: - Slightly slower GraphAdjacencyIndex.rebuild() (one-time init cost) - High-level queries still use optimized index - Import performance unaffected (writes don't trigger init) - NO breaking changes to public API TESTING: - Added 4 regression tests (tests/regression/v5.7.0-deadlock.test.ts) - All 1146 existing tests pass ✅ - Import + relationships complete in <1 second (not 760+) - No 12+ second delays per entity ✅ FILES CHANGED: - src/storage/baseStorage.ts (reverted lines 2320-2444 to v5.6.3) - tests/regression/v5.7.0-deadlock.test.ts (new regression tests) - CHANGELOG.md (comprehensive v5.7.1 entry with upgrade instructions) VERIFICATION: Workshop team should upgrade immediately: npm install @soulcraft/brainy@5.7.1 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-11 15:24:43 -08:00
const start = Date.now()
// Import 5 entities with relationships
const importedEntities = []
for (let i = 0; i < 5; i++) {
const id = await brain.add({
data: `Imported Entity ${i}`,
type: 'person',
metadata: {
importId: 'test-import-001',
sourceRow: i
}
})
importedEntities.push(id)
}
// Add relationships
for (let i = 0; i < 4; i++) {
await brain.relate({
from: importedEntities[i],
to: importedEntities[i + 1],
type: VerbType.Knows
})
}
const elapsed = Date.now() - start
// In v5.7.0, this took 12+ seconds per entity (60+ seconds total)
// In v5.7.1, should complete in <5 seconds for 5 entities
expect(elapsed).toBeLessThan(5000)
// Verify all entities were created
for (const id of importedEntities) {
const entity = await brain.get(id)
expect(entity).toBeDefined()
}
})
it('should allow GraphAdjacencyIndex rebuild without circular dependency', async () => {
// Create initial data
const entity1 = await brain.add({ data: 'Node A', type: 'thing' })
const entity2 = await brain.add({ data: 'Node B', type: 'thing' })
const entity3 = await brain.add({ data: 'Node C', type: 'thing' })
await brain.relate({ from: entity1, to: entity2, type: VerbType.RelatedTo })
await brain.relate({ from: entity2, to: entity3, type: VerbType.RelatedTo })
// Accessing storage internals should not cause deadlock
// GraphAdjacencyIndex initialization should complete successfully
const start = Date.now()
// This would trigger initialization if not already done
const relations = await brain.getRelations({ from: entity1 })
const elapsed = Date.now() - start
// Should be fast (no deadlock, no 12s delays)
expect(elapsed).toBeLessThan(500)
expect(relations).toHaveLength(1)
expect(relations[0].to).toBe(entity2)
})
it('should handle multiple concurrent adds without deadlock', async () => {
// Simulate concurrent entity creation (like batch import)
const start = Date.now()
const promises = []
for (let i = 0; i < 10; i++) {
promises.push(
brain.add({
data: `Concurrent Entity ${i}`,
type: 'thing',
metadata: { batch: true, index: i }
})
)
}
const ids = await Promise.all(promises)
const elapsed = Date.now() - start
// Should complete quickly (no 12s per entity delays)
// 10 entities should take <2 seconds, not 120+ seconds
expect(elapsed).toBeLessThan(2000)
expect(ids).toHaveLength(10)
})
})