Duplicator version update breaks it

Here’s more information from tech support at Dreamhost: (note that I tested with all other plugins disabled)

WordPress 7.1
PHP 8.3.30
Duplicator 5.0.2

I also checked the previous Duplicator logs and confirmed that you were
already using DupArchive, so there is no need to switch the archive
engine.

ARCHIVE Type=DUP Mode=DupArchive

I then tested the same admin ajax endpoint that Duplicator uses for its
loopback request.

The direct request completed successfully.

AJAX_HTTP=200
TTFB=1.805659s
TOTAL=1.805945s
AJAX_BODY=ok

The same test performed through the WordPress HTTP API also completed
successfully.

WP_LOOPBACK=PASS
HTTP=200
TIME=1.683s
BYTES=2

I also checked the PHP FastCGI processes during the test. Only one PHP
process was active at that time.

PHP_PROCESS_COUNT=1

To test whether several loopback requests would exhaust the available PHP
processes, I sent three requests at the same time.

All three returned HTTP 200.

REQ=1 HTTP=200 TOTAL=1.815026s
REQ=3 HTTP=200 TOTAL=5.287642s
REQ=2 HTTP=200 TOTAL=5.525003s

I also reviewed the recent logs for FastCGI errors, ModSecurity blocks,
and HTTP 500, 502, 503, and 504 responses during this test.

No matching errors were found.

RECENT DUPLICATOR 500 AND 503 ACCESS EVENTS

No matching entries

FASTCGI MODSEC AND SERVER ERROR EVIDENCE

No matching entries

There was an earlier FastCGI process exhaustion event in the server logs,
so that condition did occur previously.

mod_fcgid: cannot apply process slot for /dh/cgi-system/php83.cgi

At that time, the server was unable to start another PHP process until an
existing process became available.

However, the new testing does not reproduce that condition, and we do not
currently have evidence showing that DupArchive itself caused the FastCGI
exhaustion before the backup started.

The most useful finding came directly from the current Duplicator trace
log.

Duplicator recorded the following message several times during its
kickoff test.

KICKOFF TEST: probe rejected
no pending probe or code mismatch

The messages were recorded repeatedly at 01:42 on September 11.

01:42:02 probe rejected
01:42:05 probe rejected
01:42:07 probe rejected
01:42:11 probe rejected

This means that the request is reaching the Duplicator code, but
Duplicator is rejecting its own kickoff probe because there is no pending
probe or because the probe code does not match what it expects.

I also found earlier failed Duplicator builds where Duplicator itself
eventually cancelled the process.

Package 22 has been going for 90.082505683104 minutes so cancelling

RUNTIME ERROR

Backup creation failed

Conclusion.

The current tests show that the DreamHost server can successfully process
the Duplicator admin ajax loopback request.

The endpoint currently returns HTTP 200, WordPress can reach the same
endpoint, several simultaneous requests also complete, and the PHP
process pool was not exhausted during our testing.

There is also no current evidence of a ModSecurity block or FastCGI error
during these tests.

The earlier FastCGI exhaustion was a real event, but the current evidence
does not confirm that Duplicator archive creation caused it.

The strongest current evidence is the Duplicator 5.0.2 trace message
stating that the kickoff probe was rejected because there was no pending
probe or there was a code mismatch.

Because of this, the current issue appears more closely related to the
Duplicator kickoff process itself, or a possible interaction between
Duplicator and another WordPress plugin, rather than a persistent server
block.

Since you mentioned that other users are reporting similar behavior after
Duplicator version 5 was released, I recommend providing the Duplicator
support team with the exact trace message below.

Duplicator 5.0.2
WordPress 7.1
PHP 8.3.30

ClientSideKick.php
confirmLoopbackProbe

KICKOFF TEST: probe rejected
no pending probe or code mismatch

This should give their developers a more specific starting point than a
general loopback failure.

It would also be useful to temporarily test Duplicator with the other
WordPress plugins disabled, preferably on a staging copy or during a safe
maintenance period.

If Duplicator works with the other plugins disabled, the plugins can then
be enabled one at a time until the conflict is identified.

If the same kickoff error continues when Duplicator is the only active
plugin, this would provide stronger evidence that the behavior is
specific to Duplicator 5.0.2.