make runs persistent#33
Conversation
| _, _, messages = await database.get_thread_history(user_id=user.id, thread_id=thread_id, run_id=run_id) | ||
| return pydantic.TypeAdapter(list[schema.AugmentedMessage]).validate_python(messages, from_attributes=True) | ||
|
|
||
| @router.sse("/{threadId}/runs", methods=["POST"], response_model=schema.Event, tags=["Runs"]) |
There was a problem hiding this comment.
This is the only intended BC break:
- old:
POST {threadId}/run - new:
POST {threadId}/runs
There was a problem hiding this comment.
why the impetus for the change? IMHO a POST endpoint should be a verb, not a noun.
There was a problem hiding this comment.
Runs are now a proper object. So this becomes a regular CRUD endpoint alongside
GET /api/threads/{threadId}/runsGET /api/threads/{threadId}/runs/{runId}
|
I've made one comment so far, but this is a big PR. Could you please provide some commentary on its purpose and what we achieve by adopting it? |
| name: str | None = None | ||
| agent_id: str | ||
| created_at: datetime | ||
| updated_at: datetime |
There was a problem hiding this comment.
A thread is never updated anymore, but rather a new run will be added. For ordering the threads on a "last updated" basis, order by the created_at timestamps of the runs.
| name: str | None = None | ||
| agent_id: str | ||
| created_at: datetime | ||
| updated_at: datetime |
There was a problem hiding this comment.
TODO: add runs as part of the model
| class AugmentedMessageMixin(BaseModel): | ||
| id: str = Field(default_factory=lambda: str(uuid.uuid4())) | ||
| created_at: datetime = Field(default_factory=now) | ||
| updated_at: datetime | None = None |
There was a problem hiding this comment.
Messages are no longer updated, but rather revisioned. This is just internal and the created_at timestamp can be used for ordering.
AG-UI supports branching and time-travel on a per-run basis. So far ravnar has no concept of a run beyond the name being used in the endpoint that kicks on off. This PR introduces a persistent run object, with each thread being a tree of runs. This is optional and client can still use a linear history. Any BC breaking changes are called out below.