Extend health endpoint

[mtrezza]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

The /parse/health endpoint only returns a single key status: 'ok' without any contextual information such as:

• status may be ok, but there may be internal processes going on that are health related
• status may be not ok, in which case there should be additional information returned

Feature / Enhancement Description

Currently "status" is a final state that is only related to the final result of the server start. The suggestion is to make "status" a dynamic state that can change at anytime during runtime and returns the current server health throughout the server lifecycle. This would make the status more versatile for future server health features. One could set an alarm to continuously watch the server status. For example:

{
  status: "degraded",
  code: 1,
  warnings: [
    {
      code: 123,
      message: "Database connection fails."
    }
  ]
}

We could add the following status:

• unknown: returned by the health endpoint by default, even before server begins initializing
• pending: server is starting up
• ok: all good, server has started
• severe: there are some issues the developer should look into, server is not running

There could also be warnings and infos like:

{
  status: "ok",
  code: 0,
  warnings: [
    {
      code: 123,
      message: "Intermittent database connection errors."
    }
  ],
  infos: [
    {
      code: 124,
      message: "Android push notification certificate expires in 29 days."
    }
  ]
}

Example Use Case

n/a

Alternatives / Workarounds

n/a

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[Moumouls]

@mtrezza I can suggest to add to the spec to only keep status key when master key is not provided.
If master key is provided on the health endpoint it's safe to return additional & internal status.

Or a CLP object could be introduced to allow some users to access to the status details, and avoid a master key usage.

[mtrezza]

Yes, that's a good point. I think this whole feature needs some more thought. The discussion where this originally came up has evolved so that the HTTP response code now for example also changes depending on the status.