Extend health endpoint - Githubissues

mtrezza commented 1 year ago

New Feature / Enhancement Checklist

[x] I am not disclosing a vulnerability.
[x] I am not just asking a question.
[x] 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[bot] commented 1 year ago

Thanks for opening this issue!

🎉 We are excited about your ideas for improvement!

Moumouls commented 1 year ago

@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.