Skip to content

Assistant: startup cache flush wipes all live sessions #1523

Description

@dannon

The lifespan handler calls cache_service.flush_all() on startup (backend/api/app/main.py:63), and that is a bare redis.flushdb() (backend/api/app/core/cache.py:77) -- it drops the entire Redis database.

Assistant sessions live in that same database under assistant:session:* (SESSION_PREFIX, backend/api/app/services/session_service.py:13), so every backend restart destroys every in-flight conversation. Rate-limit counters and auth sessions share the instance too.

In prod that means every deploy boots everyone who is mid-conversation, and they come back to "Failed to restore the previous conversation." With a 2h session TTL this is not self-limiting -- it happens as often as we deploy.

Repro: start a conversation, restart the API, reload /assistant.

The flush is presumably there to drop stale catalog/response cache on deploy. It should not be taking sessions with it. Options:

  • scope the flush to the cache key prefix instead of flushdb(), or
  • put sessions on a separate Redis DB / instance the flush does not touch

Found while smoke-testing the assistant locally ahead of dropping the feature flag (#1288).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status
No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions