-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] First basic draft of the dispatch system using Redis #1310
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NAICE
Reminder that this is on the blocking path for moving to the UI but it looks simple and well advanced enough that we likely will have it ready by tomorrow \o/ |
Yes! Will do my best to unlock the API layer asap.
…On Thu, Sep 7, 2023 at 5:23 PM Stanislas Polu ***@***.***> wrote:
Reminder that this is on the blocking path for moving to the UI but it
looks simple and well advanced enough that we likely will have it ready by
tomorrow \o/
—
Reply to this email directly, view it on GitHub
<#1310 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACXUNPEK7NX6ZRCFDVYIYTXZHRHVANCNFSM6AAAAAA4PCFC5I>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
The new port is dor the http layer of qdrant
…On Thu, Sep 7, 2023 at 5:22 PM Stanislas Polu ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In docker-compose.yml
<#1310 (comment)>:
> ports:
- 6334:6334
+ - 6333:6333
why this change?
—
Reply to this email directly, view it on GitHub
<#1310 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACXUNLNVKJBTCXDMQOK2NLXZHRD5ANCNFSM6AAAAAA4PCFC5I>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
re qdrant, do we need it? |
Re qdrant port: I use it often for debugging vis curl. |
Gotcha I realize now this is not impacting production 👍 |
👍 side note but Qdrant cloud exposes this port, and I also use it there for debugging / profiling sometimes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If conversation sub (which I presume you created for minimal testing) then LGTM
}, | ||
}); | ||
res.status(200).end(); | ||
await p; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need the await? why not void?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually a few comments
front/lib/api/assistant/pubsub.ts
Outdated
while (true) { | ||
const events = await client.xRead( | ||
{ key: pubsubChannel, id: lastEventId ? lastEventId : "0-0" }, | ||
{ COUNT: 1, BLOCK: 10000 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the plan with 10s here? what happens once it's reached?
There is a weird behavior that I am not understanding yet with the
subscribe (sub) endpoint.
Give me a bit more time before using it (~15 minutes).
…On Fri, Sep 8, 2023 at 1:26 PM Stanislas Polu ***@***.***> wrote:
***@***.**** approved this pull request.
If conversation sub (which I presume you created for minimal testing) then
LGTM
------------------------------
In front/pages/api/v1/w/[wId]/assistant/[cId]/messages/index.ts
<#1310 (comment)>:
> + // not sure how to provide the content here for now.
+ content: [],
+ visibility: conv.visibility,
+ },
+ message: payload.message,
+ mentions: [],
+ context: {
+ timezone: payload.context.timezone,
+ username: payload.context.username,
+ fullName: payload.context.fullName,
+ email: payload.context.email,
+ profilePictureUrl: payload.context.profilePictureUrl,
+ },
+ });
+ res.status(200).end();
+ await p;
do we need the await? why not void?
------------------------------
In front/pages/api/v1/w/[wId]/assistant/[cId]/messages/index.ts
<#1310 (comment)>:
> + const conv = await Conversation.findOne({
+ where: {
+ sId: req.query.cId as string,
+ },
+ });
+ if (!conv) {
+ return apiError(req, res, {
+ status_code: 404,
+ api_error: {
+ type: "conversation_not_found",
+ message: "Conversation not found.",
+ },
+ });
+ }
+
+ // no time for actual io-ts parsing right now, so here is the expected structure.
roger sounds good 👍
—
Reply to this email directly, view it on GitHub
<#1310 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACXUNKTGG45JX3MEQCHWK3XZL6FXANCNFSM6AAAAAA4PCFC5I>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
a6834c4
to
09d1bd3
Compare
Ready for review on my side. |
front/lib/api/assistant/pubsub.ts
Outdated
const events = await client.xRead( | ||
{ key: pubsubChannel, id: lastEventId ? lastEventId : "0-0" }, | ||
// weird, xread does not return on new message when count is = 1. Anything over 1 works. | ||
{ COUNT: 10, BLOCK: 60 * 1000 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// weird
right in the middle of the dispatch system is not great.
COUNT must have an impact no? Does it work if we have more than 10 events in the queue?
}); | ||
} | ||
|
||
const conv = await Conversation.findOne({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's remove the Conversation loading for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if we call getConversationEvents on a bogus sId?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it will block until the timeout has been reached out and return 0 event.
while (true) { | ||
const events = await redis.xRead( | ||
{ key: pubsubChannel, id: lastEventId ? lastEventId : "0-0" }, | ||
// weird, xread does not return on new message when count is = 1. Anything over 1 works. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey! Reading the code to prepare, thanks for all that aric 🙏
NRE - Just asking : something I don't understand here: if we use count = 1 then only 1 event on the array max right, and no need for the loop below? Why not get e.g. count = 100, to limit the calls to redis -- and keep the loop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to drop in uninvited 😅 hope I'm not disturbing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For context: this comment was wrong, count is honored, I am not sure exactly if redis can return more than 1 event when using the blocking call because I have read that it returns on the first one, but for the first call with no "lastEventId" set, it does return multiple rows.
In any case, that's the redis interface, they always return an array, so we'll always have to loop. We could fetch event[0] but it does not change the code much I think. Does it?
This is a first draft of what the dispatch system could look like, using Redis streams.
The two main Redis commands used are:
XADD
to add data to a "persistent stream".XREAD
to read data from the persistant stream.Let me know what you think.