Skip to content

Conversation

@khouadrired
Copy link

based on #30

@coderabbitai
Copy link

coderabbitai bot commented Feb 9, 2026

📝 Walkthrough

Walkthrough

This PR restructures the monitor-worker-server service layer by reorganizing classes into dedicated sub-packages (external/client, external/adapter, internal, messaging) and renames REST service classes to REST client classes. All dependent code and tests are updated accordingly.

Changes

Cohort / File(s) Summary
StepExecutionService & Related
AbstractProcess.java, SecurityAnalysisProcess.java, ProcessTest.java
Updated import path for StepExecutionService to new services.internal package location.
REST Client Migrations (Step Classes)
ApplyModificationsStep.java, SecurityAnalysisRunComputationStep.java
Migrated from service classes to new REST client types; constructor parameters and field types updated accordingly.
Service Adapter Reorganization
FilterService.java, NetworkConversionService.java, NetworkModificationService.java
Moved to services.external.adapter package; internal imports updated. NetworkConversionService replaced RestTemplate-based initialization with CaseRestClient dependency.
New REST Client Classes
CaseRestClient.java, FilterRestClient.java, NetworkModificationRestClient.java, ReportRestClient.java, SecurityAnalysisRestClient.java
Relocated and/or renamed from services to services.external.client package. Classes renamed to standardized *RestClient naming convention.
Internal & Messaging Services
ProcessExecutionService.java, StepExecutionService.java, ConsumerService.java, NotificationService.java
Moved to services.internal and services.messaging packages respectively. Updated imports for reorganized dependencies.
Import Path Updates (LoadNetworkStep)
LoadNetworkStep.java, LoadNetworkStepTest.java
Updated import path for NetworkConversionService to new services.external.adapter location.
Test Updates – Client Renames
FilterRestClientTest.java, NetworkModificationRestClientTest.java, ReportRestClientTest.java, SecurityAnalysisRestClientTest.java
Renamed test classes and updated package paths to match client class migrations; @RestClientTest annotations and field references updated.
Test Package Relocations
ProcessTest.java, SecurityAnalysisProcessTest.java, ApplyModificationsStepTest.java, SecurityAnalysisRunComputationStepTest.java
Test classes moved to match source package reorganization; imports and mock field types updated to use new REST client classes.
Adapter Test Reorganization
FilterServiceTest.java, NetworkModificationServiceTest.java
Moved to services.external.adapter test package; no behavioral changes.
Complex Test Refactoring
NetworkConversionServiceTest.java
Refactored from @RestClientTest to Mockito-based test setup; replaced RestTemplate mocking with CaseRestClient and CaseDataSourceClient mocks.
Comprehensive Service Test Updates
ProcessExecutionServiceTest.java, StepExecutionServiceTest.java, ConsumerServiceTest.java, NotificationServiceTest.java
Moved to respective internal/messaging packages; updated mock field types from service classes to new REST client types (e.g., NetworkModificationRestClient, SecurityAnalysisRestClient).
New Test Addition
CaseRestClientTest.java
Introduces new unit test for CaseRestClient with basic instantiation and return type verification.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

  • thangqp
  • klesaulnier

Poem

🐰 A hop through packages neat and tidy,
REST clients spring where services stood,
Internal, external, messaging divide-y,
Cleaner structure, organized wood!
Tests dance along, refactored with glee

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title 'organize monitor-worker-server services' clearly and concisely reflects the main change—a reorganization of service packages and structure throughout the codebase.
Description check ✅ Passed The description references a related PR in the monitor-core repository, providing context about the refactoring basis and demonstrating this is part of a broader coordinated change.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch GRD-3891-refactor-monitor-worker-server-services-structure

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Feb 9, 2026

@khouadrired khouadrired requested a review from thangqp February 9, 2026 15:00
@khouadrired khouadrired marked this pull request as ready for review February 9, 2026 15:00
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
monitor-worker-server/src/main/java/org/gridsuite/monitor/worker/server/services/external/client/SecurityAnalysisRestClient.java (1)

31-33: ⚠️ Potential issue | 🟡 Minor

Double-slash in URL construction.

The default base URI ends with / (http://security-analysis-server/), DELIMITER is /, and the path from UriComponentsBuilder starts with /. This produces URLs like http://security-analysis-server//v1//results/{resultUuid}. While most HTTP clients and servers tolerate double slashes, this is fragile and could cause issues with stricter servers or proxies.

If you adopt the rootUri pattern suggested above, this is resolved automatically. Otherwise, strip trailing slashes from the base URI or avoid leading slashes in the path.

Also applies to: 46-52

🧹 Nitpick comments (6)
monitor-worker-server/src/main/java/org/gridsuite/monitor/worker/server/services/external/client/ReportRestClient.java (1)

64-69: RestTemplate.exchange errors (non-JSON) are not caught.

sendReport only catches JsonProcessingException. HTTP errors from restTemplate.exchange (e.g., RestClientException on 4xx/5xx) will propagate as unchecked exceptions. This is pre-existing behavior, but worth noting as this class is now explicitly positioned as a REST client — callers should be aware of potential RestClientExceptions.

monitor-worker-server/src/test/java/org/gridsuite/monitor/worker/server/services/external/client/CaseRestClientTest.java (1)

27-34: Test is quite shallow — consider verifying the UUID is passed through.

The isInstanceOf(CaseDataSourceClient.class) assertion is redundant since the return type is compile-time enforced. The test currently only proves the constructor doesn't throw. Consider asserting that the returned CaseDataSourceClient is actually wired with the correct caseUuid (e.g., by inspecting a field or calling a method on it), which would give this test more value.

That said, the @RestClientTest wiring verification itself is useful.

monitor-worker-server/src/main/java/org/gridsuite/monitor/worker/server/services/internal/StepExecutionService.java (1)

60-67: Verify report is not lost on failure path.

When step.execute(context) succeeds but reportRestClient.sendReport(...) on Line 62 throws, the step status is set to FAILED (Line 65) and the exception propagates. This means the step's work is done but the report is lost. This was the same behavior before the refactor (with reportService), so it's not a regression — but worth noting as a pre-existing reliability concern: the report send could be retried or handled separately from the step status.

monitor-worker-server/src/main/java/org/gridsuite/monitor/worker/server/services/external/client/SecurityAnalysisRestClient.java (1)

28-39: Inconsistent REST client pattern vs. CaseRestClient.

CaseRestClient bakes the base URI into the RestTemplate via restTemplateBuilder.rootUri(baseUri).build(), while this class stores the URI separately and manually prepends it at call time. Using the same pattern across all clients in external.client would improve consistency and reduce error surface.

Also, the @Setter on securityAnalysisServerBaseUri makes this mutable on a singleton @Service — presumably for tests. Consider using constructor injection only (matching CaseRestClient's approach) and using @RestClientTest or @TestPropertySource in tests instead.

♻️ Suggested alignment with CaseRestClient pattern
-    private final RestTemplate restTemplate;
-
-    `@Setter`
-    private String securityAnalysisServerBaseUri;
-
-    private String getSecurityAnalysisServerBaseUri() {
-        return this.securityAnalysisServerBaseUri + DELIMITER + SA_API_VERSION + DELIMITER;
-    }
-
-    public SecurityAnalysisRestClient(
-        RestTemplateBuilder restTemplateBuilder,
-        `@Value`("${gridsuite.services.security-analysis-server.base-uri:http://security-analysis-server/}") String securityAnalysisServerBaseUri) {
-        this.securityAnalysisServerBaseUri = securityAnalysisServerBaseUri;
-        this.restTemplate = restTemplateBuilder.build();
-    }
+    private final RestTemplate restTemplate;
+
+    public SecurityAnalysisRestClient(
+        `@Value`("${gridsuite.services.security-analysis-server.base-uri:http://security-analysis-server/}") String securityAnalysisServerBaseUri,
+        RestTemplateBuilder restTemplateBuilder) {
+        this.restTemplate = restTemplateBuilder.rootUri(securityAnalysisServerBaseUri).build();
+    }
monitor-worker-server/src/main/java/org/gridsuite/monitor/worker/server/services/external/client/FilterRestClient.java (1)

42-52: getBody() may return null.

restTemplate.exchange(...).getBody() can return null, which would propagate a null list to callers. This pre-dates this PR, but since you're touching this class, consider adding a null guard or returning an empty list as a fallback.

Proposed defensive null handling
         try {
-            return restTemplate.exchange(filterServerBaseUri + path, HttpMethod.GET, null, new ParameterizedTypeReference<List<AbstractFilter>>() { }).getBody();
+            List<AbstractFilter> body = restTemplate.exchange(filterServerBaseUri + path, HttpMethod.GET, null, new ParameterizedTypeReference<List<AbstractFilter>>() { }).getBody();
+            return body != null ? body : List.of();
         } catch (HttpStatusCodeException e) {
monitor-worker-server/src/test/java/org/gridsuite/monitor/worker/server/services/external/client/NetworkModificationRestClientTest.java (1)

77-85: Consider adding a test for null input.

The production code uses CollectionUtils.isNotEmpty(modificationsUuids) which also handles null. You have a test for an empty list but not for null input. A brief test would ensure the guard works for both cases.

💡 Suggested test for null input
+    `@Test`
+    void getModificationsWithNull() {
+        List<ModificationInfos> resultListModifications = networkModificationRestClient.getModifications(null);
+        assertThat(resultListModifications).isEmpty();
+    }

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.

2 participants