-
Notifications
You must be signed in to change notification settings - Fork 3
Introduce Azure Event Grid Notification Service #15
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
- added new service - added configuration - added tests
- created eventgrid wrapper - added additional payload tests
|
@arktronic-sep - I'm unsure the best way to test and validate the work that I did. Would love to chat about it sometime! Let me know best way to move forward. |
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.
Pull Request Overview
This PR introduces Azure Event Grid integration as a notification service for the sama monitoring application. The service sends structured events to Azure Event Grid when endpoint status changes occur or management operations are performed.
- Adds EventGridNotificationService that implements INotificationService to send events to Azure Event Grid
- Integrates the new service with dependency injection and configuration system
- Includes comprehensive unit tests covering all notification scenarios
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| unit-tests/Services/EventGridNotificationServiceTests.cs | Comprehensive test suite covering all notification methods and event payload validation |
| sama/sama.csproj | Adds Azure.Messaging.EventGrid package dependency |
| sama/Startup.cs | Registers EventGridNotificationService and wrapper in DI container |
| sama/Services/SettingsService.cs | Adds configuration properties for Event Grid topic endpoint and access key |
| sama/Services/EventGridPublisherClientWrapper.cs | Testable wrapper around Azure EventGridPublisherClient |
| sama/Services/EventGridNotificationService.cs | Main service implementing INotificationService for Event Grid notifications |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| // Avoid async warning by not awaiting the result since we're testing the call was made | ||
| _ = result2; |
Copilot
AI
Sep 11, 2025
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 comment and discard pattern is unnecessary. The variable assignment can be removed entirely since the verification is already complete in the Received() call.
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's not entirely wrong. We should be awaiting rather than assigning to a result variable, though. (Why is it named result2 when there isn't a result1?)
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
|
also, add place to configure settings for event grid. |
Co-authored-by: Copilot <[email protected]>
use file scoped namespace make endpoint subjects consistent
|
@arktronic-sep - I think I'm all set. I made the suggested changes, and added the settings fields. Here is a screenshot showing that messages are flowing into the Azure Event Grid topic: Please take a look when you can so we can get this sent over to IT. Thanks! |
|
|
||
| namespace sama.Services; | ||
|
|
||
| public class EventGridNotificationService : INotificationService |
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.
Minor: spacing was not reformatted after switching namespace style
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.
will def fix.
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.
pushed an update.
| _eventGridWrapper = eventGridWrapper; | ||
| } | ||
|
|
||
| private static class EventTypes |
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.
Why a class here? It just contains const strings, so couldn't they exist in the parent class?
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.
just to collect them all together. just how my brain wanted to organize them. no pref either way for me.
| private static string Subject(string path) => $"Sama/{path}"; | ||
| private static string EndpointSubject(string path) => Subject($"endpoints/{path}"); |
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.
- Is
Subjectused anymore (aside from inEndpointSubject)? - Minor: spacing inconsistency
- Minor: as these are methods, they should be verbified
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.
Another minor question: why does the Subject capitalize the first letter in sama? Is this an Event Grid convention?
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.
hehe - that's a good question! no, I don't think it's an EventGrid convention. I think I'll switch it to all lowercase sama.
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.
Subject isn't used outside of EndpointSubject. That said, I still like the separation of concepts, if that makes sense.
| [TestMethod] | ||
| public void NotifyMiscShouldExecuteInBackgroundForEndpointReconfigured() | ||
| { | ||
| var endpoint = CreateTestHttpEndpoint(); | ||
|
|
||
| _service.NotifyMisc(endpoint, NotificationType.EndpointReconfigured); | ||
|
|
||
| _bgExec.Received(1).Execute(Arg.Any<Action>()); | ||
| } | ||
|
|
||
| [TestMethod] | ||
| public void ShouldNotExecuteWhenTopicEndpointIsNotConfigured() | ||
| { | ||
| _settings.Notifications_EventGrid_TopicEndpoint.Returns((string)null); | ||
| var endpoint = CreateTestHttpEndpoint(); | ||
| var result = new EndpointCheckResult { Success = true }; | ||
|
|
||
| _service.NotifySingleResult(endpoint, result); | ||
|
|
||
| // Should still call Execute, but the async function inside should return early | ||
| _bgExec.Received(1).Execute(Arg.Any<Action>()); | ||
| } |
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'm a bit confused about these tests... they aren't validating the data received, which seems like it'd be important. And the tests named ShouldNotExecute* all expect that Execute is, in fact, called.
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 first one - I would personally not validate the data, just verify that it executed. There are other tests that verify the payload.
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.
Updated the rest of the ShouldNotExecute* tests. Good find!
| ) | ||
| ); | ||
|
|
||
| // Avoid async warning by not awaiting the result since we're testing the call was made |
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 believe, verifying async calls is generally done with await. Not sure what warning this would be. For some examples, take a look at SlackNotificationServiceTests.
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 think it was confused a bit. The warning shows up I think when you don't mark the method async. I marked them async and changed it back to await. All seems well!
- update sama subject name - remove result variables - update "shouldnotexecute..." tests
|
Alright - one more round if you want to take another look! Thanks! |

refers to issue #14 .