Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
NIFI-16339
Two unit/system tests contain timing-sensitive race conditions that intermittently fail CI on unrelated pull requests, forcing maintainers to re-run jobs. This PR makes both tests tolerant of valid asynchronous state transitions without changing any production behavior.
TestStandardProcessScheduler.validateNeverEnablingServiceCanStillBeDisableddisableControllerService(...)is asynchronous. When disabling a controller service whose@OnEnabledis still blocked, the node may already have reachedDISABLEDby the time the test inspects the state, rather than being observed in the intermediateDISABLINGstate. Both are valid outcomes, so the strict equality assertion is timing-dependent and fails on fast/loaded runners (observed onWindows Zulu JDK 21):The assertion now accepts either
DISABLINGorDISABLED.PythonNarDeletionDuringInitIT.testNarReuploadAfterForceDeleteDuringInitAfter a re-uploaded NAR reaches
INSTALLED, processor-type discovery can lag briefly, so a single immediate lookup can returnnulland failassertNotNull. The test now polls for the processor type (200 ms interval, 30 s monotonic deadline) before asserting.Out of scope
Several clustered/system tests intermittently hit their 5-minute
@Timeoutduring node startup on CI (worst onubuntu-24.04 Java 25). The failing test rotates run-to-run (e.g.AutoResumeStateClusteredIT,OffloadContentClaimTruncationIT,FlowSynchronizationIT,ClusteredConnectorTroubleshootingIT,ControllerServiceStateIT). Because there is no single root cause in test logic (only shared timeout pressure), these are tracked separately as CI/runner performance flakiness and are not addressed here.Tracking
Issue Tracking
Pull Request Tracking
NIFI-00000NIFI-00000Pull Request Formatting
mainbranchVerification
Please indicate the verification steps performed prior to pull request creation.
Build
./mvnw clean install -P contrib-checkLicensing
Documentation