-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat(coderd): add new dispatch logic for coder inbox #16764
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
Conversation
dannykopping
left a comment
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.
Good start, a few things we need to address but none of them huge.
coderd/notifications/manager_test.go
Outdated
| require.Eventually(t, func() bool { | ||
| success, failure := mgr.BufferedUpdatesCount() | ||
| return success == expectedSuccess && failure == expectedFailure | ||
| return success == expectedSuccess*2 && failure == expectedFailure*2 // Each message is enqueued twice. |
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.
Your tests are going to become complicated once inbox can be disabled (by feature flag or otherwise).
I'd suggest creating a func which returns the configured targets and then you can len them instead of hardcoding magic numbers like this.
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.
I tried to clean it up a bit - still not perfect but as we do not have FF or experiment logic, please tell me if that's good enough.
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.
No I think we need to take this further; there are several other places relying on this magic number.
|
|
||
| // Build fingerprints for the two different series we expect. | ||
| methodTemplateFP := fingerprintLabels(notifications.LabelMethod, string(method), notifications.LabelTemplateID, tmpl.String()) | ||
| methodTemplateFPWithInbox := fingerprintLabels(notifications.LabelMethod, string(database.NotificationMethodInbox), notifications.LabelTemplateID, tmpl.String()) |
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 metrics for inbox?
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.
I kept it to avoid any specific logic and as I felt like it could be interesting to have - no real other reason tbh.
| }, | ||
| "data": null | ||
| "data": null, | ||
| "targets": null |
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.
I guess we're never testing with targets?
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.
def not as much as we could - I added one on the logic but we can improve the golden files.
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.
Which golden file did that update? I don't see it.
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.
Ok I took a bit longer than expected , but this targets never changes - it is part of the buildPayload which takes directly data fetched from db that does not contain the targets.
I'd like to clean it up as a follow-up PR, seems like there's some mixed fields with targets - one within the payload and another one outside of it.
defelmnq
left a comment
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.
Thanks @dannykopping for the first review - I tried to fix all your comments. 🙏
Just still have an open comment on the FF for inbox.
|
|
||
| // Build fingerprints for the two different series we expect. | ||
| methodTemplateFP := fingerprintLabels(notifications.LabelMethod, string(method), notifications.LabelTemplateID, tmpl.String()) | ||
| methodTemplateFPWithInbox := fingerprintLabels(notifications.LabelMethod, string(database.NotificationMethodInbox), notifications.LabelTemplateID, tmpl.String()) |
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.
I kept it to avoid any specific logic and as I felt like it could be interesting to have - no real other reason tbh.
coderd/notifications/manager_test.go
Outdated
| require.Eventually(t, func() bool { | ||
| success, failure := mgr.BufferedUpdatesCount() | ||
| return success == expectedSuccess && failure == expectedFailure | ||
| return success == expectedSuccess*2 && failure == expectedFailure*2 // Each message is enqueued twice. |
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.
I tried to clean it up a bit - still not perfect but as we do not have FF or experiment logic, please tell me if that's good enough.
| // THEN: we expect to see all but the final attempts failing | ||
| // the number of tries is equal to the number of messages times the number of attempts | ||
| // times 2 as the Enqueue method pushes into both the defined dispatch method and inbox | ||
| nbTries := msgCount * maxAttempts * 2 |
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 we conditionalize when inbox is used in the future, this will become brittle and it won't be easily understood why; this is why magic numbers are to be avoided at all reasonable costs.
coderd/notifications/manager_test.go
Outdated
| require.Eventually(t, func() bool { | ||
| success, failure := mgr.BufferedUpdatesCount() | ||
| return success == expectedSuccess && failure == expectedFailure | ||
| return success == expectedSuccess*2 && failure == expectedFailure*2 // Each message is enqueued twice. |
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.
No I think we need to take this further; there are several other places relying on this magic number.
| }, | ||
| "data": null | ||
| "data": null, | ||
| "targets": null |
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.
Which golden file did that update? I don't see it.
|
I fixed most of the comments, but would like to create two follow-up PR :
|
| NotificationName: "test", | ||
| NotificationTemplateID: notifications.TemplateWorkspaceDeleted.String(), | ||
| UserID: "1e965b51-9465-43d8-ac20-c5f689f9c788", | ||
| UserID: "valid", |
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.
How is valid a valid UserID?
dannykopping
left a comment
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.
Approving to unblock, and for the outstanding comments to be addressed in a follow-up.
I would like to see the magic numbers replaced with a functional call to express which delivery targets are active (this will help when we allow multiple targets plus inbox, later). Having the feature flag (default on, possible opt-out) will naturally expose the need for this.
We just need to ensure this PR does not get cherry-picked into a release, otherwise customers will have no way to turn it off.
This PR is resolving the dispatch part of Coder Inbocx.
Since the DB layer has been merged - we now want to insert notifications into Coder Inbox in parallel of the other delivery target.
To do so, we push two messages instead of one using the
Enqueuemethod.