Add GlobalNotifier to the app #100
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cruikshanks
added a commit
that referenced
this pull request
Jan 31, 2023
https://eaflood.atlassian.net/browse/WATER-3833 Found when working on [Add GlobalNotifier to the app](#100). If we get an error response from the [SROC Charging Module API](https://github.com/DEFRA/sroc-charging-module-api) we are able to parse the result without issue. This is because it will have a JSON body. But if Got throws an exception, which it will do if it fails to get a response, for example, when the request times out then `result.response` won't have a `body` property. This is causing the `_parseResult()` method to throw an error; `Unexpected token u in JSON at position 0`. This change updates `_parseResult()` in `CreateBillRunService` to be able to handle both scenarios.
Cruikshanks
added a commit
that referenced
this pull request
Jan 31, 2023
https://eaflood.atlassian.net/browse/WATER-3833 Found when working on [Add GlobalNotifier to the app](#100). If we get an error response from the [SROC Charging Module API](https://github.com/DEFRA/sroc-charging-module-api) we are able to parse the result without issue. This is because it will have a JSON body. But if **Got** throws an exception, which it will do if it fails to get a response, for example, when the request times out then `result.response` won't have a `body` property. This is causing the `_parseResult()` method to throw an error; `Unexpected token u in JSON at position 0`. This change updates `_parseResult()` in `CreateBillRunService` to be able to handle both scenarios.
https://eaflood.atlassian.net/browse/WATER-3833 Whilst working on [Flag bill runs as errored on CHA failure](#99) we realised that by no longer throwing an error and sending them back via [Boom](https://hapi.dev/module/boom/) we'd lose any logs or notifications that the request to the Charge Module had failed. We want to log this and send a notification to our [Errbit](https://github.com/errbit/errbit) instance. Looking at what we have though, all our [notification](app/lib) logic is tied up with the [Hapi request](https://hapi.dev/api/?v=21.1.0#request). We don't need to know the specific request which failed on in this case, as it avoids passing it around. But we also want to avoid instantiating both the [Airbrake notifier](https://github.com/airbrake/airbrake-js/tree/master/packages/node) and [Pino](https://github.com/pinojs/hapi-pino) every time we want to log something. So, as an example, our [RequestNotifierPlugin](app/plugins/request-notifier.plugin.js) takes advantage of the work the [AirbrakePlugin](app/plugins/airbrake.plugin.js) does to set up the Airbrake notifier. We'll add a plugin that does something similar but adds the 'notifier' (our name for something that can both log and send something to Errbit) to the [Node global namespace](https://nodejs.org/api/globals.html#globals_global) instead of the request. We'll then have something we can reuse anywhere whilst instantiating only once per process. We're aware of the 'never use globals' rule. But as with all rules, there is always an exception!
We can't use app/lib/base-notifier.lib.js directly because it expects a child class to override its formatting functions. So, we need to add a new notifier class. We use [SROC Charging Module API's TaskNotifierLib](https://github.com/DEFRA/sroc-charging-module-api/blob/main/app/lib/task_notifier.lib.js) as template.
Got started on the plugin and realised we have both a Pino and Airbrake instance available on the server object. So, we can expect both to be passed to the constructor. But to ensure we are getting existing instances rather than generating our own through BaseNotifierLib we add some logic to throw an error if any of the args are `null`.
With our plugin we make an instance of GlobalNotifierLib available for use anywhere in the app. Because we're adding a global variable we have to let labrc. It has checks to help stop global variables being inadvertently created.
Now if either the `get()` or `post()` functions in `RequestLib` fail we'll both log the error and send a notification to Airbrake.
Cruikshanks
force-pushed
the
add-global-notifier
branch
from
4997bd2 to
dc6854f
Compare
Jozzey
approved these changes
Feb 6, 2023
StuAA78
approved these changes
Feb 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://eaflood.atlassian.net/browse/WATER-3833
Whilst working on Flag bill runs as errored on CHA failure we realised that by no longer throwing an error and sending them back via Boom we'd lose any logs or notifications that the request to the Charge Module had failed.
We want to log this and send a notification to our Errbit instance. Looking at what we have though, all our notification logic is tied up with the Hapi request.
We don't need to know the specific request which failed in this case, as it avoids passing it around. But we also want to avoid instantiating both the Airbrake notifier and Pino every time we want to log something.
So, as an example, our RequestNotifierPlugin takes advantage of the work the AirbrakePlugin does to set up the Airbrake notifier.
We'll add a plugin that does something similar but adds the 'notifier' (our name for something that can both log and send something to Errbit) to the Node global namespace instead of the request. We'll then have something we can reuse anywhere whilst instantiating only once per process.
We're aware of the 'never use globals' rule. But as with all rules, there is always an exception!
Screenshot of error in Errbit