e2b-dev / e2b-dev/runtime

fix(shared): ConnectionLimiter retains zero-count map entries on Release (memory leak)

Open Beginner friendly
#3,448 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
1.6k
Forks
438
PR merge metrics
No merged PRs in 30d

Description

Problem

ConnectionLimiter in packages/shared/pkg/connlimit tracks and enforces per-key concurrent connection limits. When connections are acquired and subsequently released back to zero, Release(key) decrements the counter to 0, but never removes the key entry from the underlying concurrent map (smap.Map[*atomic.Int64]).

For long-running proxy nodes (client-proxy and orchestrator/pkg/tcpfirewall) handling high request volume across ephemeral client IPs or sandboxes, inactive keys remain permanently allocated in memory with count 0, causing steady memory accumulation over time.

Root Cause

Release(key) decrements counter.Load() to 0 via CompareAndSwap(current, current-1) but lacks eviction logic when current - 1 == 0. Calls to Remove(key) are only manually issued upon sandbox deletion in orchestrator, leaving generic HTTP proxy and TCP firewall IP keys orphaned forever.

Setting / Factor Current Value / State Intended / Expected
File / Component packages/shared/pkg/connlimit/limiter.go:L48-L63 Automatic zero-count key eviction
Map Retention Retains zero-count keys indefinitely ((N_{\text{total_unique_keys}})$) Evicts zero-count keys on release ((N_{\text{active_concurrent_keys}})$)

Reproduction Steps

  1. Acquire and release 10,000 unique keys using TryAcquire(key, limit) followed by Release(key).
  2. Inspect limiter.connections.Count().
  3. Observed result: Count() returns 10000 (10,000 zero-count map entries retained).
  4. Expected result: Count() returns 0.
limiter := connlimit.NewConnectionLimiter()
for i := 0; i < 10000; i++ {
    key := fmt.Sprintf("key-%d", i)
    limiter.TryAcquire(key, 5)
    limiter.Release(key)
}
// limiter.connections.Count() remains 10000

Technical Context

  • Files affected: packages/shared/pkg/connlimit/limiter.go, packages/shared/pkg/connlimit/limiter_test.go
  • Subsystem: Shared / Client Proxy / Orchestrator TCP Firewall
  • Impact: Medium (Memory accumulation on edge proxy nodes)

Proposed Changes

# Change File(s) Affected Complexity
1 Atomically evict zero-count keys in Release(key) using RemoveCb packages/shared/pkg/connlimit/limiter.go Low
2 Add unit tests verifying zero-count map key eviction packages/shared/pkg/connlimit/limiter_test.go Low

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with packages/shared/pkg/connlimit/limiter.go, especially Release and the concurrent map operations, then read the related cases in packages/shared/pkg/connlimit/limiter_test.go. Run the connlimit tests and reproduce the 10,000-key scenario. Done means released keys no longer remain in the map while existing limit and concurrent-release behavior still passes.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
networking
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.