feat(backend, auth): /healthz fails if a database is not connected

[njlie]

Changes proposed in this pull request

• Before responding to requests on the /healthz endpoint, both the backend and auth services will try to reach both its postgres database and its redis instance and responding appropriately based on the result.

Context

Closes RAF-1172.

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Make sure that all checks pass
• Bruno collection updated (if necessary)
• Documentation issue created with user-docs label (if necessary)
• OpenAPI specs updated (if necessary)

[netlify]

✅ Deploy Preview for brilliant-pasca-3e80ec ready!

Name	Link
🔨 Latest commit	571a7c0
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/6925fa4198cca100082ab3c4
😎 Deploy Preview	https://deploy-preview-3717--brilliant-pasca-3e80ec.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[BlairCurrey]

this removal seems to be resulting in the 500 errors on backend/integration/performance tests.

I had assumed the 500 errors were coming from the new healthcheck but as I traced it that didnt make much sense and reverting the healthz changes didnt fix the issue.

I guess this was probably removed in error, and the non-null assertion on the logger class property didnt help. We can simply return it.

It's a small thing, but we could probably just assign logger/config in the constructor to bypass the need for the non-null assertion. That would require changing the container singletons to not (unnecessarily?) return promises. Which should be fine. We have this pattern of making them return promises but it seems entirely unnecessary for logger, config, and most others.

export interface AppServices {
  logger: Promise<Logger>
  telemetry: Promise<TelemetryService>
  internalRatesService: Promise<RatesService>
  knex: Promise<Knex>
  axios: Promise<AxiosInstance>
  config: Promise<IAppConfig>
  httpTokenService: Promise<HttpTokenService>
  ... etc

Then that makes it looks like maybe we can even just move the entire boot function to the constructor, since it no longer needs to be async. That would also change some timing though (currently we do constructor, then other stuff, then boot) but I dont think that should matter. Guess it's a little can of worms and we should at least just return the line here.

[njlie]

Yeah for now I'll just reintroduce the deleted line.

[github-actions]

🚀 Performance Test Results

Test Configuration:

• VUs: 4
• Duration: 1m0s

Test Metrics:

• Requests/s: 45.49
• Iterations/s: 15.19
• Failed Requests: 0.00% (0 of 2737)

📜 Logs

> [email protected] run-tests:testenv /home/runner/work/rafiki/rafiki/test/performance
> ./scripts/run-tests.sh -e test "-k" "-q" "--vus" "4" "--duration" "1m"

Cloud Nine GraphQL API is up: http://localhost:3101/graphql
Cloud Nine Wallet Address is up: http://localhost:3100/
Happy Life Bank Address is up: http://localhost:4100/
cloud-nine-wallet-test-backend already set
cloud-nine-wallet-test-auth already set
happy-life-bank-test-backend already set
happy-life-bank-test-auth already set
     data_received..................: 988 kB 16 kB/s
     data_sent......................: 2.1 MB 35 kB/s
     http_req_blocked...............: avg=8.57µs   min=2.43µs   med=4.98µs   max=2.09ms   p(90)=6.2µs    p(95)=6.71µs  
     http_req_connecting............: avg=1.38µs   min=0s       med=0s       max=2.02ms   p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=87.32ms  min=7.87ms   med=71.03ms  max=523.21ms p(90)=149.93ms p(95)=173.09ms
       { expected_response:true }...: avg=87.32ms  min=7.87ms   med=71.03ms  max=523.21ms p(90)=149.93ms p(95)=173.09ms
     http_req_failed................: 0.00%  ✓ 0         ✗ 2737
     http_req_receiving.............: avg=86.13µs  min=26.38µs  med=71.15µs  max=3.32ms   p(90)=109.92µs p(95)=142.06µs
     http_req_sending...............: avg=36.55µs  min=10.66µs  med=26.75µs  max=2.24ms   p(90)=40.13µs  p(95)=55.73µs 
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=87.2ms   min=7.69ms   med=70.88ms  max=523.12ms p(90)=149.83ms p(95)=172.85ms
     http_reqs......................: 2737   45.486506/s
     iteration_duration.............: avg=263.09ms min=157.15ms med=251.09ms max=1.07s    p(90)=320.86ms p(95)=353.06ms
     iterations.....................: 914    15.189867/s
     vus............................: 4      min=4       max=4 
     vus_max........................: 4      min=4       max=4