greentic-session
Greentic’s session manager persists flow execution state between user interactions. A session is
represented by greentic_types::SessionData, which bundles the tenant context, flow identifier,
cursor, and serialized execution snapshot so a runner can pause a Wasm flow, wait for input, and
resume exactly where it left off.
Highlights
- Shared schema – The crate reuses the
greentic_typesdefinitions forSessionKey,SessionData,TenantCtx, andUserId, ensuring every runtime speaks the same language when storing or resuming a flow. - Pluggable stores – The
SessionStoretrait exposes a compact CRUD surface (create_session,get_session,update_session,remove_session,find_by_user). There is a thread-safe in-memory implementation plus a Redis implementation for multi-process deployments. - User routing – Each store maintains a secondary map from
(env, tenant, team, user)to aSessionKeyso inbound activities can be routed to the correct paused flow without the caller needing to supply the opaque session identifier. - Deterministic key helpers – The
mappingmodule offers helpers for deriving stableSessionKeyvalues from connector payloads (e.g., Telegram update fields or webhook metadata).
SessionStore API
use ;
use ;
All stores persist the full SessionData blob so the runner can deserialize the exact execution
context it previously saved. When find_by_user returns a result, the runner can call
update_session with the resumed snapshot (or remove_session once the flow completes).
Quickstart
use InMemorySessionStore;
use SessionStore;
use ;
Run the example with cargo run --example quickstart to see the same flow end-to-end.
Choosing a backend
| Feature flag combo | Backend availability | Suggested usage |
|---|---|---|
default (redis) |
Redis + in-memory | Production runners |
--no-default-features --features inmemory |
In-memory only | Tests, single-node dev |
--all-features |
Redis + schema docs | CI / documentation generation |
The Redis backend stores each SessionData blob as JSON under
greentic:session:session:{session_key} and maintains user lookup keys at
greentic:session:user:{env}:{tenant}:{team}:{user}. When a session is removed, the lookup entry is
cleared so new activities fall back to creating a fresh session.
Deterministic Session Keys
mapping::telegram_update_to_session_key(bot_id, chat_id, user_id)mapping::webhook_to_session_key(source, subject, id_hint)
Both helpers derive a SHA-256 digest and hex-encode it, making it safe to hash stable identifiers
without leaking PII. Use them when the connector should resume the same session even if the runtime
doesn’t issue a SessionKey (e.g., webhooks that only provide conversation IDs).
Development
Redis tests honor the REDIS_URL environment variable. If unset, the Redis-specific tests are
skipped automatically.