Skip to content
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

Merged

Conversation

ivan-p-nikolov
Copy link
Contributor

Remove profiler endpoints.
Fix bug preventing service to shutdown gracefully.
Add support for listening for multiple topics.
Add new subscription type Annotations.

@ivan-p-nikolov ivan-p-nikolov requested a review from a team January 7, 2020 13:23
@epavlova epavlova self-requested a review January 7, 2020 13:26
dispatch/notifications.go Outdated Show resolved Hide resolved
dispatch/notifications.go Outdated Show resolved Hide resolved
APIURL: n.APIBaseURL + "/" + n.Resource + "/" + event.ContentID,
PublishReference: transactionID,
ContentType: dispatch.AnnotationContentType,
LastModified: time.Now().Format(time.RFC3339),
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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_test.go Outdated Show resolved Hide resolved
consumer/publish_event.go Outdated Show resolved Hide resolved
resources/push.go Show resolved Hide resolved
func (h *metadataQueueHandler) HandleMessage(queueMsg kafka.FTMessage) error {
msg := NotificationQueueMessage{queueMsg}
tid := msg.TransactionID()
monitoringLogger := log.WithMonitoringEvent("NotificationsPush", tid, "annotations update")
Copy link

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.

@@ -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()
Copy link

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.

Copy link
Contributor Author

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.

@ivan-p-nikolov ivan-p-nikolov force-pushed the feature/UPPSF-981-add-annotations-notifications branch from c1e8e12 to 0bd3e0c Compare January 9, 2020 14:40
@coveralls
Copy link

coveralls commented Jan 9, 2020

Coverage Status

Coverage decreased (-0.6%) to 65.473% when pulling 79a7766 on feature/UPPSF-981-add-annotations-notifications into 6435d06 on master.

@ivan-p-nikolov ivan-p-nikolov force-pushed the feature/UPPSF-981-add-annotations-notifications branch from 0bd3e0c to ea299b2 Compare January 9, 2020 14:47
APIURL: n.APIBaseURL + "/" + n.Resource + "/" + event.ContentID,
PublishReference: transactionID,
ContentType: dispatch.AnnotationContentType,
LastModified: time.Now().Format(time.RFC3339),
Copy link
Contributor

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/publish_event.go Outdated Show resolved Hide resolved
@ivan-p-nikolov ivan-p-nikolov force-pushed the feature/UPPSF-981-add-annotations-notifications branch from ea299b2 to abd9a46 Compare January 13, 2020 12:24
@ivan-p-nikolov ivan-p-nikolov force-pushed the feature/UPPSF-981-add-annotations-notifications branch from abd9a46 to f910e0d Compare January 14, 2020 13:05
Add configuration for whitelisting annotation origins
Change notification schema - `Standout` is not mandatory now
Change dispatcher mock to be able to override methods.
@ivan-p-nikolov ivan-p-nikolov force-pushed the feature/UPPSF-981-add-annotations-notifications branch from f910e0d to 9496b06 Compare January 15, 2020 08:24
Copy link
Contributor

@MiroslavGatsanoga MiroslavGatsanoga left a 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.

@ivan-p-nikolov ivan-p-nikolov merged commit 5ba7d0f into master Jan 17, 2020
ivan-p-nikolov added a commit that referenced this pull request Jan 23, 2020
Feature/UPPSF-981 Add Annotations Notifications
@ivan-p-nikolov ivan-p-nikolov deleted the feature/UPPSF-981-add-annotations-notifications branch February 21, 2020 15:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants