Cached responses 200 -> 304

[n10000k]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

When using a health check route @HealthCheck() within a controller the response is cached.

It originally returns the 200 status code then as now the result is cached it's returning 304.

This will cause issues for kubernetes and other services trying to read 200 status code, then maybe retrying to get a cached result for of 304.

Minimum reproduction code

  @Get('ping')
  @HealthCheck()
  public ping(): string {
    return 'pong';
  }

Steps to reproduce

No response

Expected behavior

Set Cache-Control to no-store

Package version

latest

NestJS version

latest

Node.js version

18.1

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

A work around for people is to apply @Header('Cache-Control', 'no-store') under @HealthCheck()

[BrunnerLivio]

Thanks for you report! I personally don't think it's a good idea to add this to Terminus directly. I think @Header('Cache-Control', 'no-store') is the way to go as you've described. Though I think wouldn't hurt to update the documentation.

I'm open to change my mind though if other people face the same issue and had to do the same workaround?

[n10000k]

Yeah it's one to understand where the responsibility of the cache is owned at this point.

My argument for adding it to Terminus (as a condition to turn on and off cache: false/true, by default no caching enabled) is that you wrap your route in the @HealthCheck() decorator. When doing a health check you want the actual results vs cached results.

Use case being that if you're doing checks in Kubernetes or other deployment methods/services that allow for health checking you want to know real time that the service is up and not some old out dated previous cached result that maybe during that time you ran out of memory, database crashed etc.

[matt2415]

I had this issue too and had to use the work around.

[BrunnerLivio]

After further considerations I have implemented this feature #2335

[BrunnerLivio]

Released with v10.1.0 🎉

[n10000k]

Thanks @BrunnerLivio !