[frontend/backend] Use healthchecks to manage inject readyness (#4263)

[gabriel-peze]

Proposed changes

• Use healthchecks to evaluate inject readyness and add more details into inject missing content state
• Improve code by removing complex methods from DTOs and Entities

Testing Instructions

1. Check for inject readyness state and details into scenarios injects, should not be changed but should have more details into the scenario readyness tooltip.

Related issues

• Closes Improve inject readiness with healthchecks #4263

[codecov]

Codecov Report

❌ Patch coverage is 84.59530% with 59 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.14%. Comparing base (d68b3d8) to head (5457f35).
⚠️ Report is 15 commits behind head on release/current.

Files with missing lines	Patch %	Lines
...io/openaev/healthcheck/utils/HealthCheckUtils.java	87.50%	7 Missing and 11 partials ⚠️
...va/io/openaev/rest/inject/SimulationInjectApi.java	12.50%	14 Missing ⚠️
...rc/main/java/io/openaev/rest/inject/InjectApi.java	15.38%	11 Missing ⚠️
...n/java/io/openaev/service/InjectImportService.java	0.00%	7 Missing ⚠️
...java/io/openaev/rest/inject/ScenarioInjectApi.java	70.58%	5 Missing ⚠️
...va/io/openaev/rest/inject/output/InjectOutput.java	60.00%	0 Missing and 2 partials ⚠️
...n/java/io/openaev/healthcheck/dto/HealthCheck.java	96.15%	1 Missing ⚠️
...io/openaev/scheduler/jobs/InjectsExecutionJob.java	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@                  Coverage Diff                  @@
##             release/current    #4277      +/-   ##
=====================================================
+ Coverage              49.45%   50.14%   +0.69%     
- Complexity              3564     3620      +56     
=====================================================
  Files                    887      886       -1     
  Lines                  26427    26623     +196     
  Branches                1965     1977      +12     
=====================================================
+ Hits                   13069    13351     +282     
+ Misses                 12569    12476      -93     
- Partials                 789      796       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[RomuDeuxfois]

question: I don’t quite understand this change — the DTO seems to be turning into something that looks like the original entity.
This could lead to performance issues if we end up returning the full inject object, which contains a large number of properties.
What’s the reason behind this change?

[gabriel-peze]

We shouldn't add the healthchecks informations to the Inject entity because there is no healthcheck information into the database, so we have to use a DTO to return the informations with healthchecks.
To avoid any regression, the InjectOutput have to hold the same informations as before, but the process didn't change.
All attributes exist into the InjectOutput, but it doesn't mean every time an InjectOutput is returned to the frontend all attributes are set.
For example, for the inject search, only a few informations are set to the InjectOutput object, the ones needed to display a light list of inject. And the get one Inject API still return the full informations as before.

[RomuDeuxfois]

question: This isn’t directly related to the PR, but I don’t quite understand the purpose of runInjectsChecksFor.
From what I can tell, it seems to act as a kind of garbage collector for health checks that weren’t handled earlier — but why weren’t they?
It makes the code feel quite repetitive. Why do we need to handle it this way?

[gabriel-peze]

The new healthchecks are the ones who creates the missing content failure, we want to filter them because the cause of the missing content is not linked to the scenario. Only the missing content information are important for the scenario.

For other checks (like SMTP, IMAP, Collector, etc), the only check to do is to verify if, into the injects healthcheck, the failure exist, and because into the injects healthcheck all checks are not necessary related to the scenario (Missing body, subject, asset, etc) we can't simply add all the injects checks to the scenario, and instead, verify the match into the injects checks.

[RomuDeuxfois]

Haven’t tested that part yet — just doing some code review to understand the mechanisms in place.

[gabriel-peze]

TO DO :

• Rollback InjectOutput DTO but keep isReady and healthchecks
• Remove InjectOutput from InjectApi returns, for search (who need isReady info) use InjectOutput as return
• If isReady is necessary in Java code, simply check for injectService.runContentCheck result
• Add a comment to scenario checks, why we have to do all the runInjectsChecksFor