feat: conversation sharing#977
Conversation
JakPing
commented
Apr 24, 2026
Code Coverage SummaryDetailsDiff against mainResults for commit: d21c343 Minimum allowed coverage is ♻️ This comment has been updated with latest results |
6d409ff to
243bbe5
Compare
453a335 to
8af36ee
Compare
9dcb144 to
e680d52
Compare
Adds end-to-end conversation sharing built on top of the new core storage system: share API routes, SharePersistence + SQL backend, shared-chat example, UI share button/banner/icon, and tests.
e680d52 to
132b192
Compare
| "ConversationShareResponse", | ||
| "ConversationMeta", | ||
| "ConversationInteractionData", | ||
| "ConversationDetail", |
There was a problem hiding this comment.
Are all of these responses for sure? Or maybe some of them should be in core_data array?
There was a problem hiding this comment.
Based on the current model semantics, those four are imo correctly placed under responses, not core_data.
| deleteConversation: (conversationId: string) => void; | ||
| deleteConversation: ( | ||
| conversationId: string, | ||
| ragbitsClient?: RagbitsClient, |
There was a problem hiding this comment.
shouldnt this type be as required?
There was a problem hiding this comment.
deleteConversation is designed to always remove locally, and only hit the API when a client is available, so i would leave it as is.
| console.log( | ||
| "[Guard] effect fire " + | ||
| JSON.stringify({ | ||
| conversationId, | ||
| isKnown, | ||
| isTemp, | ||
| isServerOnly, | ||
| loading, | ||
| conversations, | ||
| }), | ||
| ); |
puzzle-solver
left a comment
There was a problem hiding this comment.
Overall, I think that this PR looks very good and we definitely need to include that in a new release. I think many projects may benefit from having a backend conversation history persistence, since so far it had to be manually implemented.
Left some nit picks in the comments, but the main thing I would suggest is a separate set up of conversation endpoints for storing conversation and for sharing them. From my experience with client projects, we may often want to have server-side history persistence, without thinking about setting up conversation sharing.
| @@ -0,0 +1,38 @@ | |||
| """SQL store abstractions. | |||
There was a problem hiding this comment.
Are we planning to use this module? Right now, a persistence of chat history is done with a sqlalchemy ORM, which I quite like. With this approach, we would need to operate on untyped dicts.
Not strongly against it, but I would be interested to know what are we going to do with this code.
| return router | ||
|
|
||
|
|
||
| def build_share_router( |
There was a problem hiding this comment.
I would delete this one, since this is a new PR and on existing code uses "build_share_router"