Skip to content

Fix health endpoint scanner availability checks#13

Open
Trishanthsai wants to merge 4 commits into
ionfwsrijan:mainfrom
Trishanthsai:issue-9-health-check
Open

Fix health endpoint scanner availability checks#13
Trishanthsai wants to merge 4 commits into
ionfwsrijan:mainfrom
Trishanthsai:issue-9-health-check

Conversation

@Trishanthsai
Copy link
Copy Markdown

Linked issue

Closes #9

What this PR does

Updated the /health endpoint to check whether semgrep, osv-scanner, and gitleaks are available on the system. The endpoint now returns the availability of each scanner and reports the status as degraded when one or more scanners are missing.

Type of change

  • Bug fix

ML tier (if applicable)

  • Not ML-related

Changes

Backend

  • Added scanner availability checks using shutil.which()
  • Added scanner status information to the /health response
  • Added degraded status when any scanner is unavailable

Testing

How did you test this?

Ran the backend locally and verified the /health endpoint response in the browser. Confirmed that scanner availability is reported correctly and the status changes to degraded when scanners are not installed.

Checklist

  • No new console.error or unhandled Python exceptions introduced

Anything reviewers should focus on

Health status logic and scanner availability checks.

@ionfwsrijan
Copy link
Copy Markdown
Owner

@sasidaran-99 Tests fail.

@Trishanthsai
Copy link
Copy Markdown
Author

Hi @ionfwsrijan will look into this and will update

@ionfwsrijan
Copy link
Copy Markdown
Owner

Hey @Trishanthsai! The core logic looks good. shutil.which() is the right approach and the degraded status works correctly. A few things before this can be merged:

  1. Breaking change: ok field removed — the original /health returned {"ok": True}. Your new response only returns status and scanners, which silently breaks anything checking for ok. Either keep it for backwards compatibility:
return {
    "ok": True,
    "status": status,
    "scanners": scanners,
}

...or confirm nothing in the frontend depends on it and document the shape change in the PR description.

2 Frontend piece is missing — the issue spec included a warning banner in the UI when status is "degraded". That's not in this PR. Either add it here or open a separate follow-up issue for it. Either is fine, just needs tracking.

Fix these and this is good to merge!

@Trishanthsai
Copy link
Copy Markdown
Author

Hi @ionfwsrijan,

I've restored the ok field in the health endpoint response for backward compatibility and pushed the update.

For the frontend warning banner when the health status is degraded, I couldn't find any existing health-check integration in the UI. Since the current issue is focused on the backend health endpoint, I suggest tracking the UI banner as a separate follow-up issue unless you'd prefer it to be included in this PR.

Thanks!

@ionfwsrijan
Copy link
Copy Markdown
Owner

@Trishanthsai That LGMT as well. You may raise a followup issue. Also pls resolve the merge conflicts with the main

@Trishanthsai
Copy link
Copy Markdown
Author

Hi @ionfwsrijan,

I've resolved the merge conflicts with main. The PR now shows no conflicts with the base branch.

It looks like the remaining workflow is awaiting maintainer approval. Could you please approve/re-run it when you get a chance?

Also, I'll raise a follow-up issue for the frontend degraded-status warning banner as discussed.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

/health endpoint does not check if scanners are actually available on PATH

2 participants