PTFE-1196 ping redis on healthcheck calls

[tcarmet]

No description provided.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (4964aff) 85.45% compared to head (edbddb1) 85.55%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #503      +/-   ##
==========================================
+ Coverage   85.45%   85.55%   +0.09%     
==========================================
  Files          31       31              
  Lines        1169     1177       +8     
==========================================
+ Hits          999     1007       +8     
  Misses        170      170              

Flag	Coverage Δ
api	66.35% <100.00%> (+0.23%)	⬆️
unit	70.51% <0.00%> (-0.57%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nootal]

I'm all for pinging Redis, but is this going to fix the issue where the API goes south and returns "Internal Server Error" when redis is back on track?

[tcarmet]

I'm all for pinging Redis, but is this going to fix the issue where the API goes south and returns "Internal Server Error" when redis is back on track?

The internal server errors were returned because the API was unable to contact the redis server. The reason why it was unable to do so remains a mistery, but regardless of the reason the healthcheck will fail (especially as there could be multiple reason that lead to the same symptom).

When a healthcheck fails, Kubernetes will restart the service accordingly. (Which is the same operation that was done manually to fix the issue)

Now, it is possible that a ping to redis may succeed but other request won't, but before we go into the route of handling all possibilities, let's start with a simple one first.