From 5528e1c35319b2dfc3a4589c824bfdebbd2f3fdf Mon Sep 17 00:00:00 2001
From: Alan Cruikshanks <alan.cruikshanks@gmail.com>
Date: Thu, 2 Mar 2023 15:30:09 +0000
Subject: [PATCH] Fix response handling for Charging Module requests

https://eaflood.atlassian.net/browse/WATER-3906

We've spotted that we're not being consistent with our response handling of requests to the [sroc-charging-module-api](https://github.com/DEFRA/sroc-charging-module-api).

We'd done some refactoring in [Refactor to use ChargingModuleRequestLib](https://github.com/DEFRA/water-abstraction-system/pull/130) to the `_parseResult()` function of `app/lib/charging-module-request.lib.js`.

The result was a calling service would receive something like

```javascript
{
  succeeded: true,
  response: {
    body: {
      billRun: {
        id: ...,
        billRunNumber: ...
      }
    },
    statusCode: ...
  }
}
```

This started blowing up when we started work on the [Spike - Create a complete debit only SROC bill run](https://github.com/DEFRA/water-abstraction-system/pull/133). This was because `app/services/supplementary-billing/initiate-billing-batch.service.js` was trying to access the result as below

```javascript
const options = {
  scheme,
  batchType: type,
  externalId: chargingModuleBillRun.response.id
}
```

And when it did blow up, our logs became spammed with hundreds of lines of [Got](https://github.com/sindresorhus/got) response info.

To resolve this we came to the conclusion that, exceptions aside, what we want from **Got** is the response body as is, plus the status code. That's it. This applies to `2xx/3xx` and `4xx/5xx` responses.

This change updates `app/lib/charging-module-request.lib.js` to ensure this.

We could have done it in `app/lib/request.lib.js` but we will be using **Got** options that may not be applicable in all cases. So, by doing it at the `charging-module-request.lib.js` level we retain flexibility in how we make requests should we need it.