[
https://issues.apache.org/jira/browse/NIFI-16339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Bij updated NIFI-16339:
---------------------------------
Description:
I'm seeing build failures caused by timing-sensitive race conditions in tests.
They
intermittently fail CI on unrelated pull requests, forcing maintainers to
re-run jobs.
h3. Affected tests
*PythonNarDeletionDuringInitIT.testNarReuploadAfterForceDeleteDuringInit*
After a NAR is re-uploaded and reaches INSTALLED, the processor type may not be
immediately
visible. The test can fail if it asserts the type is available too early.
h3. Expected behavior
- Processor type discovery should be allowed a short time to catch up after
NAR re-upload.
h3. Out of scope — separate flaky tests
Multiple clustered/system tests intermittently hit their 5-minute @Timeout
during node
startup on CI (worst on ubuntu-24.04 Java 25). The failing test rotates
run-to-run, e.g.:
- AutoResumeStateClusteredIT.testRestartWithAutoResumeStateFalse
-
OffloadContentClaimTruncationIT.testOffloadedFlowFileContentNotPrematurelyTruncated
- FlowSynchronizationIT.testReconnectAddsProcessor
- ClusteredConnectorTroubleshootingIT.*
- ControllerServiceStateIT.testLocalClusterState
Because there is no single root cause in test logic (only shared timeout
pressure), these
are tracked separately as CI/runner performance flakiness, not in this ticket.
was:
I'm seeing build failures caused by timing-sensitive race conditions in tests.
They
intermittently fail CI on unrelated pull requests, forcing maintainers to
re-run jobs.
h3. Affected tests
*PythonNarDeletionDuringInitIT.testNarReuploadAfterForceDeleteDuringInit*
After a NAR is re-uploaded and reaches INSTALLED, the processor type may not be
immediately
visible. The test can fail if it asserts the type is available too early.
*ConnectorCrudIT.testCompletedConfigVerificationRetainedWhenAnotherConnectorIsVerified*
This test already demonstrates proper timing handling: Uses the established
waitFor() utility from NiFiSystemIT
The changes eliminate intermittent CI failures while maintaining deterministic
behavior through use of monotonic time deadlines.
h3. Expected behavior
- Processor type discovery should be allowed a short time to catch up after
NAR re-upload.
h3. Out of scope — separate flaky tests
Multiple clustered/system tests intermittently hit their 5-minute @Timeout
during node
startup on CI (worst on ubuntu-24.04 Java 25). The failing test rotates
run-to-run, e.g.:
- AutoResumeStateClusteredIT.testRestartWithAutoResumeStateFalse
-
OffloadContentClaimTruncationIT.testOffloadedFlowFileContentNotPrematurelyTruncated
- FlowSynchronizationIT.testReconnectAddsProcessor
- ClusteredConnectorTroubleshootingIT.*
- ControllerServiceStateIT.testLocalClusterState
Because there is no single root cause in test logic (only shared timeout
pressure), these
are tracked separately as CI/runner performance flakiness, not in this ticket.
> Make Processor Type Discovery Test Deterministic
> ------------------------------------------------
>
> Key: NIFI-16339
> URL: https://issues.apache.org/jira/browse/NIFI-16339
> Project: Apache NiFi
> Issue Type: Test
> Components: Core Framework
> Affects Versions: 2.11.0
> Reporter: Alexander Bij
> Priority: Minor
> Labels: test-flaky
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm seeing build failures caused by timing-sensitive race conditions in
> tests. They
> intermittently fail CI on unrelated pull requests, forcing maintainers to
> re-run jobs.
> h3. Affected tests
> *PythonNarDeletionDuringInitIT.testNarReuploadAfterForceDeleteDuringInit*
> After a NAR is re-uploaded and reaches INSTALLED, the processor type may not
> be immediately
> visible. The test can fail if it asserts the type is available too early.
> h3. Expected behavior
> - Processor type discovery should be allowed a short time to catch up after
> NAR re-upload.
> h3. Out of scope — separate flaky tests
> Multiple clustered/system tests intermittently hit their 5-minute @Timeout
> during node
> startup on CI (worst on ubuntu-24.04 Java 25). The failing test rotates
> run-to-run, e.g.:
> - AutoResumeStateClusteredIT.testRestartWithAutoResumeStateFalse
> -
> OffloadContentClaimTruncationIT.testOffloadedFlowFileContentNotPrematurelyTruncated
> - FlowSynchronizationIT.testReconnectAddsProcessor
> - ClusteredConnectorTroubleshootingIT.*
> - ControllerServiceStateIT.testLocalClusterState
> Because there is no single root cause in test logic (only shared timeout
> pressure), these
> are tracked separately as CI/runner performance flakiness, not in this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
