Skip to content

Conversation

@dota-devy
Copy link

Add distributed session support via ISessionStore interface

  • Add SessionMetadata class for serializable session data
  • Create ISessionStore interface for pluggable persistence
  • Allows session recreation from persistent store
  • Add EnableDistributedSessions configuration option
  • Update DI with WithSessionStore() extension methods

dota-devy and others added 4 commits January 19, 2026 18:33
  - Add SessionMetadata class for serializable session data
  - Create ISessionStore interface for pluggable persistence
  - Implement session recreation from persistent store
  - Add EnableDistributedSessions configuration option
  - Update DI with WithSessionStore<T>() extension methods
  - Update package IDs to Surfshack.* namespace
      - Add InMemorySessionStore implementation for testing
      - Add SessionMetadataTests for basic metadata validation
      - Add InMemorySessionStoreTests covering CRUD, pruning, and thread safety
      - Add DistributedSessionTests for HTTP transport integration
@halter73
Copy link
Contributor

Sorry for the delay reviewing this. You're definitely not the only person who wants this functionality. #1155 also asks for this. However, I'm not sure an ISessionStore interface solves any problems that couldn't just be solved by using session affinity or stateless mode.

It seems like ISessionStore abstraction isn't necessary when you have session affinity and you can use the default in-memory session tracking. And when you don't have session affinity, you probably just want to use stateless mode. The shortcomings of stateless mode, which is primarily being unable to support elicitation and sampling, are not addressed by this ISessionStore interface. You need session affinity to route the elicitation and sampling response back to the server awaiting the System.Threading.Task.

Can you explain the scenario that ISessionStore addresses that is not addressed by stateless mode? If we were to do this, I'd want to use the in-memory ISessionStore by default to prove the abstractions and not require an opt-in to EnableDistributedSessions, but I think we might not need the ISessionStore abstraction at all. New protocol features like Multi Round-Trip Requests (MRTR) might make sessions even less important and allow even stateless servers without session affinity to support features like elicitation and sampling.

@dota-devy
Copy link
Author

My main reason for implementing this was that I was getting client session errors when deploying new server versions. The distributed session store fit my admittedly biased mental model of how large horizontally scaled web applications solve this issue. It's possible that stateless mode would have also been a solution.

I think you're right that instead of an opt in flag, using the ISessionStore with a default in-memory implementation that replicates the current behavior would be better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants