Clean tests instability#1010
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthrough
ChangesStudy deletion fix, async test isolation, and notification verification
Suggested Reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/test/java/org/gridsuite/study/server/loadflow/LoadFlowTest.java (1)
581-584: Consider explicitly resetting thestudyServerExecutionServicestub to follow defensive coding practices.At line 581-584, the
runAsync()method is stubbed on a shared@MockitoSpyBean. While@MockitoSpyBeandefaults toMockReset.AFTER(automatically resetting after each test), adding an explicitreset(studyServerExecutionService)at the end of the test provides a defensive guard against unexpected framework behavior changes and clarifies intent for future maintainers.This stub affects async execution behavior and could silently change test semantics if reset semantics ever diverge from expectations. A one-line reset call in the test's cleanup section would be prudent.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/test/java/org/gridsuite/study/server/loadflow/LoadFlowTest.java` around lines 581 - 584, The test is stubbing the runAsync() method on the shared studyServerExecutionService MockitoSpyBean without explicitly resetting it after the test completes. Add an explicit reset(studyServerExecutionService) call at the end of the test method (in the cleanup section or after the assertions) to defensively ensure the stub is cleared and make the intent clear for future maintainers, protecting against potential framework behavior changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/test/java/org/gridsuite/study/server/loadflow/LoadFlowTest.java`:
- Around line 581-584: The test is stubbing the runAsync() method on the shared
studyServerExecutionService MockitoSpyBean without explicitly resetting it after
the test completes. Add an explicit reset(studyServerExecutionService) call at
the end of the test method (in the cleanup section or after the assertions) to
defensively ensure the stub is cleared and make the intent clear for future
maintainers, protecting against potential framework behavior changes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5da3819d-9c77-43c2-9914-5dcef3318bca
📒 Files selected for processing (3)
src/main/java/org/gridsuite/study/server/service/StudyService.javasrc/test/java/org/gridsuite/study/server/loadflow/LoadFlowTest.javasrc/test/java/org/gridsuite/study/server/studycontroller/StudyTest.java
Meklo
force-pushed
the
marcellinh/clean_loadflow_tests_instability
branch
from
9ef2138 to
916acf3
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/main/java/org/gridsuite/study/server/service/ConsumerService.java`:
- Around line 348-350: Replace the two System.out.println statements with proper
logging using the existing LOGGER instance. The first println statement that
outputs "AAAAAAAAAAAAAAAAAAAAAAA " and checks receiver.getCaseImportAction()
should be replaced with a descriptive log message (e.g., using LOGGER.debug or
LOGGER.info) that includes the actual CaseImportAction value. The second println
statement that outputs "OOOOOOOOOOOOOOOOOOOOOOOOO" should similarly be replaced
with a meaningful log message describing the action being performed when
CaseImportAction.STUDY_CREATION is detected. This ensures proper logging
framework integration with appropriate log levels and structured output instead
of bypassing the logging configuration.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4147beba-4bfc-4ae9-b99e-f1aaae669a6b
📒 Files selected for processing (1)
src/main/java/org/gridsuite/study/server/service/ConsumerService.java
Meklo
force-pushed
the
marcellinh/clean_loadflow_tests_instability
branch
from
12dc0ec to
e5e0103
Compare
| * functions launch new threads in non blocking mode | ||
| */ | ||
|
|
||
| public static void executeAsyncOnMainThread(StudyServerExecutionService studyServerExecutionService) { |
There was a problem hiding this comment.
Same as synchronizeStudyServerExecutionService ?
There was a problem hiding this comment.
Seems like it ! I'll try swaping it with yours
| deleteStudyInfos = new DeleteStudyInfos(rootNetworkInfos, modificationGroupUuids); | ||
| } else { | ||
| studyCreationRequestRepository.deleteById(studyCreationRequestEntity.get().getId()); | ||
| studyCreationRequestEntity.ifPresent(creationRequestEntity -> studyCreationRequestRepository.deleteAllByIdInBatch(List.of(creationRequestEntity.getId()))); |
There was a problem hiding this comment.
Why deleteAllByIdInBatch ?
| removeWorkspacesConfig(s.getWorkspacesConfigUuid()); | ||
| removeNadConfigs(s.getNadConfigsUuids().stream().toList()); | ||
| }); | ||
| StudyEntity s = studyEntity.get(); |
There was a problem hiding this comment.
No need to delete something ih study is absent ?
|
2 participants
PR Summary
Two distinct causes of instability were identified and fixed.
1. Races on non-blocking async deletions
Several cleanup paths dispatch remote-resource deletions as fire-and-forget tasks via
studyServerExecutionService.runAsync(e.g.invalidateRootNetworkRemoteInfoswithblocking=false). Tests that verify those deletions race the executor pool: theverifycan run before the task does. SincedeleteCaseis the last task submitted, it's the one that fails most often (seen intestCreateRootNetworkConsumerWithoutRequest, and latent intestDeleteRootNetwork).Fix: use
synchronizeStudyServerExecutionServicewhen needed2. Double deletion of the creation request (
testCreateStudyWithErrorDuringCaseImport)On a synchronous 5xx during import,
deleteStudyIfNotCreationInProgressis called concurrently by two paths:catchblock increateStudy(request thread)consumeCaseImportFailed(RabbitMQ consumer)Depending on ordering, the consumer can read an already-deleted
study_creation_request, fall into the branch that callsgetStudy→Study not found, the exception is swallowed, and theSTUDY_CREATION_FINISHEDnotification is never emitted → the test waits for a message that never arrives.Fix:
doDeleteStudyIfNotCreationInProgressmade idempotent — if neither the creation request nor the study exists, it no-ops instead of throwing. The consumer then always reachesemitStudyCreationError, regardless of which path wins the race.