feat: Draft: Session status notification stream#650
Conversation
- removed the status filter - removed oldStatus in response, as mongos implementation to provide prechange document isnt production ready - instead of oldStatus, use a updateType, representing the reason for the update: created/updated/deleted
|
Phil Pohlmann seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
plpn90
changed the title
aneojgurhem
left a comment
aneojgurhem
left a comment
There was a problem hiding this comment.
Please remove changes unrelated to this PR
| } | ||
| } | ||
|
|
||
| message SessionEventSubscriptionRequest { } |
There was a problem hiding this comment.
If you look into Core, here is what happens with the GetEvents API.
gRPC client (EventSubscriptionRequest)
│
▼
GrpcEventsService.GetEvents
│
▼
WatchToGrpc.GetEvents
│
├─ Filter building (tasksFilter AND sessionId, resultsFilter AND sessionId)
|
├─ [parallel background tasks — all writing to Channel]
│ ├─ NewTask watcher ──► MongoDB change stream (Insert on TaskData)
│ ├─ TaskStatusUpdate watcher ──► MongoDB change stream (Update on Status)
│ ├─ NewResult watcher ──► MongoDB change stream (Insert on Result)
│ ├─ ResultStatusUpdate ──► MongoDB change stream (Update on Status)
│ ├─ ResultOwnerUpdate ──► MongoDB change stream (Update on OwnerTaskId)
│ ├─ Existing tasks (DB catch-up query)
│ └─ Existing results (DB catch-up query)
│
▼
Channel (fan-in, unbounded)
│
▼
channel.Reader.ReadAllAsync(cancellationToken)
│ yields one by one
▼
GrpcEventsService → responseStream.WriteAsync(...)
│
▼
gRPC client receives EventSubscriptionResponse stream
I think we should provide something similar for the sessions. The key parts are:
- we need to filter sessions (use existing sessions_filter) so that you can choose what to look for. Possibly, there is quite a lot of sessions in the database. Filtering on creation date can be very useful.
- As for tasks and results, i expect a NewSession Event that catch up with existing sessions in the data base then catch new additions
- .. and a SessionStatusUpdate catching every new update.
- NewSession and SessionStatusUpdate should be messages defined in the response and wrapped inside a oneof
3 participants
// DRAFT: also did some side modifications which i can undo before merge
Motivation
Needed a better way to observe changes to sessions being opened/modified/deleted, other than polling the
ListSessions()endpoint on theSessionsService.Description
Adds another endpoint on the
EventsServiceto create a notification channel for session updates.Impact
Similiar idea to how the
ChangeStreamis implemented forResults. Btw, maybe it is time to rethink how these notifications work. Wouldn't MessageQueues be a better alternative for notifying changes/updates to the system overall? Also makes it independent to MongoDB (and for it being mandatory to be a replicaset!)