-
Notifications
You must be signed in to change notification settings - Fork 2
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
Feature/UPPSF-981 Add Annotations Notifications #83
Feature/UPPSF-981 Add Annotations Notifications #83
Conversation
consumer/mapper.go
Outdated
APIURL: n.APIBaseURL + "/" + n.Resource + "/" + event.ContentID, | ||
PublishReference: transactionID, | ||
ContentType: dispatch.AnnotationContentType, | ||
LastModified: time.Now().Format(time.RFC3339), |
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.
The way this is being set, it looks very similar to the NotificationDate
field. Can't we propagate the last modified value for the annotations in similar manner as for the contents?
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 content we get LastModified
from the message body. But as far as I can see we don't have such information in the annotation message.
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.
In the native store there is a lastModified
field for the annotations, the question is do we want to propagate it through the pipeline so that we get it here. I am not sure if we are using similar approach for content so it might be a good thing to check.
consumer/metadata.go
Outdated
func (h *metadataQueueHandler) HandleMessage(queueMsg kafka.FTMessage) error { | ||
msg := NotificationQueueMessage{queueMsg} | ||
tid := msg.TransactionID() | ||
monitoringLogger := log.WithMonitoringEvent("NotificationsPush", tid, "annotations update") |
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 know that it's a bit misleading but we shouldn't have logging with WithMonitoringEvent
event here. The initial idea that our colleagues had was to log with WithMonitoringEvent
a few events that track significant events when a content is being published - saved to native store, saved to document store, notification sent. Logging in this way here would mess with that intention as this event here have nothing to do with content publishing. Although our colleagues didn't implement the monitoring based on these events, it still may be confusing and will go to the monitoring Kinesis stream with no reason.
test/mocks/mocks.go
Outdated
@@ -14,36 +14,65 @@ import ( | |||
// MockDispatcher is a mock of a dispatcher that can be reused for testing | |||
type MockDispatcher struct { | |||
mock.Mock | |||
StartFunc func() |
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.
One recommendation only - the implemented method for mocking in this PR is something that I would always choose at least as starting writing a mock object. However here we already use testify mock.Mock
which actually can do the same that we manually do with the private methods. So ideally we should have either mock.Mock
or no library for mocking and manually write the private methods and so on. I see that in the new and in the old tests we are using MockDispather
in very different ways. So the recommendation would be - if there are already a lot of tests using testify mock.Mock
there is almost no gain in implementing the manual approach for writing mocks.
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.
Apparently I was only using one of the mocked methods. So I rewrote the tests to use testify mock
.
c1e8e12
to
0bd3e0c
Compare
0bd3e0c
to
ea299b2
Compare
consumer/mapper.go
Outdated
APIURL: n.APIBaseURL + "/" + n.Resource + "/" + event.ContentID, | ||
PublishReference: transactionID, | ||
ContentType: dispatch.AnnotationContentType, | ||
LastModified: time.Now().Format(time.RFC3339), |
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.
In the native store there is a lastModified
field for the annotations, the question is do we want to propagate it through the pipeline so that we get it here. I am not sure if we are using similar approach for content so it might be a good thing to check.
ea299b2
to
abd9a46
Compare
abd9a46
to
f910e0d
Compare
Add configuration for whitelisting annotation origins Change notification schema - `Standout` is not mandatory now Change dispatcher mock to be able to override methods.
f910e0d
to
9496b06
Compare
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.
All looks good, just a couple of things that we make sure we have:
- We should add to the README some information about the new type of notifications and how to subscribe to them. Also we should point out that content type
All
applies only for content subscriptions and the newly added annotation ones. - We should be able to subscribe through the public endpoints, lets check that we are able to do that when we deploy to upper environments. We should check the API endpoint as well as both delivery clusters.
Other than that I think the PR is ready to be merged.
Feature/UPPSF-981 Add Annotations Notifications
Remove profiler endpoints.
Fix bug preventing service to shutdown gracefully.
Add support for listening for multiple topics.
Add new subscription type
Annotations
.