What were you trying to do that didn't work?

Memberof Fixup task, spawned by deferred memberof thread,  should not be started by default.

What is the impact of this issue to you?

dirsrv become unresponsive due to all workers being in use.

Packages:
¯¯¯¯¯¯¯

389-ds-base-1.4.3.39-14.module+el8.10.0+23237+0443707d.x86_64 Wed Jul 16 14:50:09 2025
389-ds-base-libs-1.4.3.39-14.module+el8.10.0+23237+0443707d.x86_64 Wed Jul 16 14:50:07 2025
ipa-client-4.9.13-18.module+el8.10.0+23182+cbb72bb2.x86_64 Wed Jul 16 14:51:25 2025
ipa-client-common-4.9.13-18.module+el8.10.0+23182+cbb72bb2.noarch Wed Jul 16 14:50:02 2025
ipa-common-4.9.13-18.module+el8.10.0+23182+cbb72bb2.noarch Wed Jul 16 14:51:24 2025
ipa-healthcheck-0.12-5.module+el8.10.0+22913+7aa1a207.noarch Fri May 16 02:59:07 2025
ipa-healthcheck-core-0.12-5.module+el8.10.0+22913+7aa1a207.noarch Fri May 16 02:59:07 2025
ipa-selinux-4.9.13-18.module+el8.10.0+23182+cbb72bb2.noarch Wed Jul 16 14:51:05 2025
ipa-server-4.9.13-18.module+el8.10.0+23182+cbb72bb2.x86_64 Wed Jul 16 14:51:27 2025
ipa-server-common-4.9.13-18.module+el8.10.0+23182+cbb72bb2.noarch Wed Jul 16 14:50:13 2025

How reproducible is this bug?:

The server crash (SIGSEV) because of unidentified bug. Upon restart the deferred member task detected
the crash and started the fixup task. The fixup task was lasting long and block any updates. If the server
receives more updates than workers, then the server becomes unresponsive
 

Expected results

Deferred memberof should by default not trigger the task but rather log a warning.

Actual results

When enabled, RFE Deferred memberof updates detects risks of invalid memberof computation.
When the server restarts after a crash, the RFE assumes memberof should be recomputed. It triggers a memberof fixup task, it is systematic.