Flag bill runs as errored on CHA failure #99
Closed
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
https://eaflood.atlassian.net/browse/WATER-3833 If we fail to create the bill run in the [Charging Module API](https://github.com/DEFRA/sroc-charging-module-api) we are currently handling the error. We ensure the app doesn't fall over, the issue gets logged and a `5xx` is returned to the client. What we are not doing is updating the `billing_batch` we created with a status of error. This means as far as the UI is concerned it's **QUEUED** waiting to be processed. This change updates the `billing_batch` record if the request to the CHA fails so that it correctly shows as errored in the UI.
We've got to add another 'thing' into the service which is updating a bill run as errored. That means they'll be even more going on in the `go()` function so it felt right to start shifting some of the 'steps' out to there own functions. The first is the step where we check if an existing bill run is already in progress.
We need to start refactoring the tests based on the new behaviour. But before we do spotted that a test about whether the charging module error includes a message or not was out of context.
Cruikshanks
added a commit
that referenced
this pull request
Jan 27, 2023
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!
|
Superseded by #104 |
Cruikshanks
added a commit
that referenced
this pull request
Jan 31, 2023
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!
Cruikshanks
added a commit
that referenced
this pull request
Feb 8, 2023
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 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!
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
If we fail to create the bill run in the Charging Module API we are currently handling the error. We ensure the app doesn't fall over, the issue gets logged and a
5xxis returned to the client.What we are not doing is updating the
billing_batchwe created with a status of error. This means as far as the UI is concerned it's QUEUED waiting to be processed.This change updates the
billing_batchrecord if the request to the CHA fails so that it correctly shows as errored in the UI.