[
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.
*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.
-
{{TestStandardProcessScheduler.validateNeverEnablingServiceCanStillBeDisabled}}
-- A controller service may transition from DISABLING to DISABLED faster than
the test expects.
-- The test currently assumes the service will still be DISABLING at assertion
time.
*Impact*
These appear to be flaky timing issues rather than functional regressions. The
tests should be made more tolerant of valid asynchronous state transitions so
the build is stable.
*Expected behavior*
Processor type discovery should be allowed a short time to catch up after NAR
re-upload.
The controller service test should accept valid terminal state transitions that
happen quickly.
was:
I’m seeing build failures caused by timing-sensitive race conditions in tests.
*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.
- `TestStandardProcessScheduler.validateNeverEnablingServiceCanStillBeDisabled`
- A controller service may transition from DISABLING to DISABLED faster than
the test expects.
- The test currently assumes the service will still be DISABLING at assertion
time.
*Impact*
These appear to be flaky timing issues rather than functional regressions. The
tests should be made more tolerant of valid asynchronous state transitions so
the build is stable.
**
*Expected behavior*
Processor type discovery should be allowed a short time to catch up after NAR
re-upload.
The controller service test should accept valid terminal state transitions that
happen quickly.
> Stabilize Python NAR reupload and controller service scheduling race
> conditions in tests
> ----------------------------------------------------------------------------------------
>
> 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
>
> I’m seeing build failures caused by timing-sensitive race conditions in tests.
> *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.
> -
> {{TestStandardProcessScheduler.validateNeverEnablingServiceCanStillBeDisabled}}
> -- A controller service may transition from DISABLING to DISABLED faster
> than the test expects.
> -- The test currently assumes the service will still be DISABLING at
> assertion time.
> *Impact*
> These appear to be flaky timing issues rather than functional regressions.
> The tests should be made more tolerant of valid asynchronous state
> transitions so the build is stable.
> *Expected behavior*
> Processor type discovery should be allowed a short time to catch up after NAR
> re-upload.
> The controller service test should accept valid terminal state transitions
> that happen quickly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
