[soyelmismo]

Problem

The Node.js process crashes with FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory within ~5 minutes of intensive use.

Root causes identified during investigation:

1. comboMetrics.ts — metrics and shadowMetrics Maps grow unboundedly (no TTL, no eviction, no cleanup timer)
2. usage.ts — 6 subscription/model caches with passive-only TTL (entries never proactively purged)
3. providerRegistry.ts — all 212 provider entries materialized eagerly at module load, even if unused

Changes

1. open-sse/services/comboMetrics.ts — Cache eviction + TTL

• MAX_METRICS_ENTRIES = 500 with LRU eviction via lastUsedAt
• METRICS_TTL_MS = 1 hour
• Cleanup setInterval every 5 minutes (.unref()'d)
• Size-cap checks in recordComboRequest, recordComboShadowRequest, recordComboIntent

2. open-sse/services/usage.ts — Proactive TTL purging

• SUB_CACHE_TTL_MS = 10 minutes
• Cleanup setInterval every 5 minutes (.unref()'d)
• Purges 4 data caches; 2 inflight Maps left alone (self-clean on Promise resolution)

3. open-sse/config/providerRegistry.ts — Lazy Proxy

• REGISTRY wrapped in a Proxy — individual provider entries materialized on first access only
• _byAlias, _unsupportedParamsMap, _passthroughProviderIds all deferred until first lookup
• getRegisteredProviders() returns pre-computed key list without eager iteration

4. scripts/check-permissions.sh — Entrypoint integration

• Entrypoint reads OMNIROUTE_MEMORY_MB and builds NODE_OPTIONS dynamically
• This was documented in .env.example but never actually implemented

Verification

• TypeScript compilation: zero new errors (pre-existing mcp-server/server.ts errors confirmed on main)
• All existing public API signatures preserved
• No function logic changes — only additive eviction/TTL/lazy-loading code
• .unref() on all timers so they don't prevent clean process exit

[gemini-code-assist]

Code Review

This pull request introduces memory management improvements, including configurable Node memory limits via OMNIROUTE_MEMORY_MB, a lazy registry proxy for provider configurations, and proactive TTL cache eviction mechanisms in comboMetrics and usage services. Feedback highlights several critical issues: the shell script incorrectly overrides the runtime memory limit due to flag ordering; the metrics eviction and cleanup logic fails to cover shadowMetrics and risks premature eviction; the lazy registry proxy adds complexity without actual memory savings since the registry is eagerly traversed at startup; and the lack of new tests for the modified production code violates Repository Style Guide Rule 9.

[kilo-code-bot]

Code Review Summary

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	2
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
open-sse/config/providerRegistry.ts	4264	getOwnPropertyDescriptor trap returns value from _REGISTRY_EAGER directly, not from cache. When get trap caches a value, getOwnPropertyDescriptor still returns the original reference, causing stale descriptors and potential memory duplication. Should check cache first.

File	Line	Issue
open-sse/services/usage.ts	1839	Proactive TTL cleanup uses SUB_CACHE_TTL_MS (10 minutes) for all 4 caches, but individual caches have different intended TTLs (ANTIGRAVITY_CACHE_TTL_MS=5min, ANTIGRAVITY_MODELS_CACHE_TTL_MS=1min, ANTIGRAVITY_CREDIT_PROBE_TTL_MS=5min). This causes antigravityAvailableModelsCache to persist ~10x longer than intended (10min vs 1min).

Other Observations (not in diff)

No issues found in unchanged code.

Files Reviewed (4 files)

• Dockerfile - No issues
• open-sse/config/providerRegistry.ts - 1 issue
• open-sse/services/comboMetrics.ts - No issues
• open-sse/services/usage.ts - 1 issue
• scripts/check-permissions.sh - No issues

---

_{Reviewed by nemotron-3-super-120b-a12b-20230311:free · 62,614 tokens}