Commit e3107d1
fix(loopback): allow wrapper creation for loopback tests from CLI
Even after the 401 is resolved, `circles:check` still fails with
"Event created too many Wrappers" (actually zero wrappers found, the
message is misleading). The LoopbackTest FederatedEvent never gets an
EventWrapper created when running from CLI.
Root cause: `initBroadcast()` has an early-return guard:
if (empty($instances) && (!$event->isAsync() || OC::$CLI))
For a LoopbackTest event (which implements IFederatedItemAsyncProcess but
has no remote instances), `$instances` is empty. Combined with
`OC::$CLI === true`, the guard returns false — skipping all wrapper
creation. This optimisation is correct for regular async events in CLI
mode, where `newEvent()` already calls `manage()` synchronously and no
async broadcast is needed. However, the LoopbackTest specifically exists
to verify that the async loopback path works end-to-end: wrapper
creation, async POST, `manageWrapper()`, and `confirmStatus()` must all
run to produce the verify/manage values that `testLoopback()` asserts.
The fix exempts events whose class implements IFederatedItemLoopbackTest
from the CLI guard, so that a wrapper is created and the async broadcast
is triggered even when running from CLI. The double call to `manage()`
(once synchronously in `newEvent()`, once asynchronously via the
wrapper) is harmless for LoopbackTest since it only sets an idempotent
result value.
Signed-Off-By: Iva Horn <iva.horn@nextcloud.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>1 parent a6009f9 commit e3107d1
1 file changed
+3
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
344 | 344 | | |
345 | 345 | | |
346 | 346 | | |
347 | | - | |
| 347 | + | |
| 348 | + | |
| 349 | + | |
348 | 350 | | |
349 | 351 | | |
350 | 352 | | |
| |||
0 commit comments