Skip to content

Conversation

jssmith
Copy link
Contributor

@jssmith jssmith commented Sep 13, 2025

What was changed

Why?

Checklist

  1. Closes

  2. How was this tested:

  1. Any docs updates needed?

await idempotence_helper.idempotent_update(conn, clear_session)


class PostgresSession(SessionABC):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I saw you aren't supposed to use SessionABC, but the underlying protocol

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's probably better.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does OpenAI provide any session implementations themselves here? Can we just write a DurableSession that wraps those instead of having to do all of the DB stuff ourselves? A DurableSession that accepts a user-provided session means they won't be limited to just specific implementations we implement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this suggestion. We might be able to use SQLAlchemySession

Copy link
Member

@cretz cretz Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or SQLiteSession since this is just a sample. I now think we should offer ActivityBasedSession that is a wrapper around third-party sessions and InWorkflowSession that is just a list implementation of session. Granted I know this is just a sample but it can save you from having a bunch of DB details in the PR while also making it clear the two approaches.

Btw, it seems the SQLiteSession is in memory by default so it would work in workflows given some sandbox avoidance work, but I think a more naive in-memory implementation makes sense over taking a SQLite dependency for what amounts to a very simple list interface.

self.session_id = session_id
self.config = config

async def get_items(self, limit: int | None = None) -> list[TResponseInputItem]:
Copy link
Member

@cretz cretz Sep 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If all of these items will end up in history anyways as a result of this call, is there any value in using a separate database instead of in-memory? Arguably it's actually worse to put the result of every call to this method in history because it may be called multiple times I assume.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Storing the conversation in both the workflow's event history and the database is somewhat redundant.

Some users want to retain a record of the conversation in a database, and this implementation meets that need. We might be able to optimize performance by deferring the database writes to when the workflow ends. However that means it isn't immediately available and will be missing if the workflow doesn't finish for some reason. The current approach defers such optimizations.

We have also explored getting the session chat history out of the workflow's event history and instead keeping references to the session stored in Postgres. However, making that work requires more changes to OpenAI Agents SDK.

Copy link
Member

@cretz cretz Sep 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Storing the conversation in both the workflow's event history and the database is somewhat redundant. [...] Some users want to retain a record of the conversation in a database, and this implementation meets that need

Makes sense, mentioned in other comment, but I think we should (also?) provide a literal InMemorySession/InWorkflowSession that is just in-memory list by default since we know that memory is durable in Temporal. I wish OpenAI would provide this in-memory session implementation, but it makes sense they don't because their memory is not durable and sessions is a naive attempt at some durability I assume.

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.

3 participants