Bug Report: MicroProfile health check endpoint reporting wrong overall status

[t-paul]

Description

Application registering a single @Liveness check returning UP still reports overall status: DOWN with HTTP response code 200.

Expected Outcome

The overall status should reflect the logic defined in HealthCheckService#constructResponse

• If the single check is UP, the overall status should be UP and HTTP return code should be 200
• If the single check is DOWN, the overall status should be DOWN and the HTTP response code should be 503.

Current Outcome

• Overall status is always DOWN
• HTTP return code always is 200 unless the check throws and exception (which is invalid according to the specification)

Debugging seems to indicate that the created HTTP response object passed into the health check service has a response code of 0 set causing the various checks for code == 200 to fail.

Steps to reproduce

health-check.zip

• Deploy application
• Navigate to /health (or /health/live) endpoint defined by microprofile health
• Refresh webpage, the probe will toggle every 10 seconds between UP and DOWN
• Observe overall status vs. check status
• Observe HTTP response code

Environment

• Distribution: Server Full Profile / v5.2022.3
• JDK Version: 11.0.16
• Operating System: Linux

[sreenath-tm]

I'm interested in contributing to this issue, so before I start working it, would you mind sparing your time explaining what the fix will be like and pointing me to some resources to get started.

[JamesHillyard]

Hi @t-paul,

Thank you for submitting a bug report, I have attempted to reproduce this however I haven't been able to observe the same results as you.

When the LivenessCheck is UP, The overall status is UP and a HTTP 200 can be observed: {"status":"UP","checks":[{"name":"LivenessCheck","status":"UP","data":{"value":"1"}}]}

When the LivenessCheck is DOWN, The overall status is DOWN and a HTTP 503 can be observed: {"status":"DOWN","checks":[{"name":"LivenessCheck","status":"DOWN","data":{"value":"18"}}]}

Is there any additional configuration required for your reproducer?

Environment

• Distribution: Payara Server 5.2022.3
• JDK Version: Zulu JDK 11.0.14
• Operating System: Windows 10 Pro / WSL 2 (Ubuntu)

Thanks, James

[t-paul]

Strange, there's no special configuration I'm aware of. I'll try again with a fresh installation.

[JamesHillyard]

Hi @t-paul,

Do you have an update on this? Have you been able to reproduce the same behaviour as me, or does this still not work on your end?

Thanks, James

[t-paul]

I tried again in the installation used earlier (which is supposed to be just downloaded package + database config via admin interface + deployed application, no special setup or anything). I'm still seeing the same effect.

I could not yet verify on a different machine, trying to check with different JDK versions. Considering that javax.servlet.http.HttpServletResponse might be the reason, not so much Payara version itself.

[JamesHillyard]

Hi @t-paul,

Thank you for providing an update on this, if it helps the exact JDK version I used was Zulu11.48+21-CA (build 11.0.11+9-LTS), I would be happy to try on the exact JDK version you are using to further try and reproduce this locally.

Thanks, James

[fturizo]

@t-paul , sorry this issue fell under the cracks, we were not able to properly review it on time initially.

Payara Community 5 is out of support, so we are closing this issue but please if you are able to test this issue on the current release of Community 6 and confirm that is no longer a problem, that'd be great.

If the issue is still present in the latest release of Community, please raise a new issue by making a full report with the reproducer so we can take a look at it.