Problem/Motivation
RemoteSubprocessTest pins execution_mode to queued in setUp(), and 32 of its 33 tests run under it. The one that sets synchronous does so to assert that the cron sweep holds the drain off; it never runs the node.
So the feature's happy-path test is synchronous only in the sense that the stubbed remote had already drained the child before answering. The local instance is queued throughout, and every assertion comes after an explicit queue drain.
The shipped default is synchronous. On a stock site the node's whole lane runs inside the inline drain, in the request that started the run: the launch, the record, the read-back of a terminal child and the advance. Nothing asserted that. The node's own class docblock singles this lane out as what differs from a local subprocess, and it was the one thing the suite did not check.
That is the blind spot two previous defects came through. A class that pins a non-default setting in setUp() is a lane nothing exercises, and a green suite says nothing about it.
Proposed resolution
Run the node's four outcomes in the shipped mode, draining no queue, because reaching the end is the assertion: a terminal child ends the run inside the start, a running one parks, a failed one routes its state, and a failed one with no state variable still leaves the answer to the sweep rather than letting the execution mode decide whether a site gets an incident or its unrecoverable-failure policy.
A documented helper puts a test in that mode, so the next person adding a test can see that the class-wide pin exists and what it hides.
Remaining tasks
None.
API changes
None. This adds test coverage only.
Data model changes
None.
User interface changes
None.
Release notes snippet
Test coverage only: the remote subprocess node is now exercised in the synchronous execution mode a stock site runs in. All four outcomes already behaved correctly, so this closes a coverage gap rather than fixing a defect.
AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the tests on the merge request. I reviewed and ran the work myself before posting it, including confirming that all four new tests fail when the execution mode they pin is removed.)
Issue fork orchestra-3623819
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mably commentedComment #5
mably commented