deleteSession() of the InMemorySessionService does not delete the user to session mapping

[c0k0619]

** Please make sure you read the contribution guide and file the issues in the rigth place. **
Contribution guide.

Describe the bug
The InMemorySessionService has the following structure for storing a session
// Structure: appName -> userId -> sessionId -> Session
private final ConcurrentMap<String, ConcurrentMap<String, ConcurrentMap<String, Session>>>
sessions;

When we do deleteSession(appName, userId, sessionId) it only removes the session but leaves back an empty map for the userId and appName

deleteSession()

What's deleted: sessionId → Session mapping
What's NOT deleted: Empty userId → {} map
What's NOT deleted: Empty appName → {} map ( This should still be fine )

Example:

BEFORE deletion:
sessions: {
"myApp": {
"user1": {
"ctx1": Session@1234
},
"user2": {
"ctx1": Session@1234
},
"user3": {
"ctx1": Session@1234
}
}
}

AFTER deletion:
sessions: {
"myApp": {
"user1": {} ← Empty map remains!
"user2": {} ← Empty map remains!
"user3": {} ← Empty map remains!
"user4": {} ← Empty map remains!
.
.
.
}
}

It can cause a potential MemoryLeak when there are a lot of users using the Agent

To Reproduce
Steps to reproduce the behavior:

1. Install '...'
2. Run '....'
3. Open '....'
4. See error

Expected behavior
An option to also delete the appName.userID map inside the InMemorySession

Screenshots
Before Deletion

After Deletion

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Java version: 21
• ADK version(see maven dependency): 0.4.0

Additional context
Add any other context about the problem here.

[prasadskarmarkar]

The Issue Is Valid, but the Impact Is Limited

Yes — the code does behave exactly as described.

What's Happening

In InMemorySessionService.deleteSession() (around line 198), the session entry is removed, but the per-user map is left behind when it becomes empty:

if (userSessionsMap != null) {
    userSessionsMap.remove(sessionId);
    // Empty userId -> {} map may remain
}

As a result, empty userId → {} maps can accumulate in memory over time.

Impact Assessment

This is better characterized as bounded memory waste, not a true memory leak:

• Bounded growth: One empty map per unique userId
• No unbounded accumulation: Growth stops once all distinct users are seen
• Small footprint: ~300 bytes per empty map

Approximate impact:

• 10,000 users → ~3 MB

While not ideal, the behavior is predictable and relatively minor.

---

InMemorySessionService Is Not Production-Ready

Per the class Javadoc (lines 45-47), this implementation is described as:

"suitable for testing or single-node deployments where persistence is not required"

This aligns with its current behavior and limitations:

❌ No persistence (sessions lost on restart)
❌ Single-node only (no horizontal scaling)
❌ No distributed locking
⚠️ Concurrent maps provide basic thread safety only

This class is intended as a testing/development utility, not a production-grade session store.

---

Production Direction: DatabaseSessionService

For production deployments, the intended solution is DatabaseSessionService, which provides:

✅ Persistent storage
✅ Multi-node / horizontal scalability
✅ Proper transactional behavior with pessimistic locking
✅ No in-memory accumulation concerns
✅ Support for PostgreSQL, MySQL, H2, SQLite, and Spanner

The database-backed implementation is currently under review here:
#654

Although that PR is still being finalized, it represents the correct long-term solution for production setups, and the in-memory implementation should not be treated as a scalable or durable alternative.

This issue does not exist in the database-backed approach because sessions are stored as rows with composite keys — there are no "empty parent containers" to accumulate.

---

Recommendation

• Use InMemorySessionService only for local development and testing
• Use DatabaseSessionService for any production deployment

Would this approach address your use case?

[c0k0619]

Hello @prasadskarmarkar

Thanks for your reply.
So the thing is we are planning to use the InMemorySessionService for Production as well, as we want to use our own Custom MemoryStore

The plan is to use an interceptor design pattern to hydrate the session of the InMemorySession instead of using DBSession and then delete that session once the execution is completed.
So the number of users in our case would be more.

If you could add a new method or modify the existing method which gives us an option to also delete the appName.userID map inside the InMemorySession would be really helpful