fix(console): write app command loading errors to stderr

[printminion-co]

Summary

When an app fails to load its console commands from info.xml, OC\Console\Application::loadCommands() reports the failure with $output->writeln() — i.e. stdout — while every other diagnostic in the same method already uses $output->getErrorOutput() (insufficient memory limit, "Nextcloud is not installed", "requires upgrade", maintenance-mode notices).

The command then runs normally and exits 0, so the message silently corrupts machine-readable output:

$ ./occ app:list --output=json
Connection refused
{"enabled":{"cloud_federation_api":"1.17.0", ...},"disabled":{...}}
$ echo $?
0

Anything piping occ <cmd> --output=json into a JSON parser breaks, and there is no non-zero exit code to detect it by. --no-warnings is not a workaround, since it sets VERBOSITY_QUIET and suppresses the payload too.

$output is typed ConsoleOutputInterface, so getErrorOutput() is guaranteed by the signature. Two call sites are affected: the app_api maintenance-mode block and the regular installed-apps loop. The logger->error() calls are unchanged, so the failure is still logged with its stack trace.

How this was hit

An app with the phpredis extension loaded but no Redis configured. RedisFactory::isAvailable() only checks extension_loaded('redis'), not whether a redis config block exists, so the app's queue factory took the Redis branch, fell back to 127.0.0.1:6379 and threw RedisException: Connection refused while its console commands were being constructed. Because enable_lazy_objects defaults to true, the constructor runs inside $this->application->add($c) → Command::setApplication(), so the throw surfaces outside loadCommandsFromInfoXml()'s inner catch (ContainerExceptionInterface) and lands in the outer catch (\Throwable).

The app-side behaviour is arguably its own issue; the console bootstrap should not corrupt stdout regardless of which app fails to load.

Verification

Reproduced deterministically with a throwaway app whose info.xml names a nonexistent command class:

	stdout	jq	stderr	exit
before	Console command '...' is un…	parse error (5)	empty	0
after	{"enabled":{...}	ok, 21 keys	the error message	0

The error remains in nextcloud.log.

On tests

No test is included. There is currently no test for lib/private/Console/*, and grep -rn getErrorOutput tests/ returns nothing, so there is no existing harness or stdout-vs-stderr assertion precedent to extend. loadCommands() also does an unstubbable require_once core/register_command.php (~138 Server::get() calls, re-fetching the real IConfig rather than an injected mock), which makes a genuine unit test a DB-group test whose result is order-dependent because require_once runs once per process.

This change adds no logic — it only redirects an existing message from one stream to the other. Happy to add a build/integration scenario (CommandLine.php already captures stdout and stderr separately) or to extract that require_once behind an injected collaborator to make the class unit-testable, if a maintainer would prefer either.

Checklist

• Code is properly formatted
• Signed-off-by is present (added by the contributor)
• Tests — see "On tests" above
• Documentation has been updated or is not required

AI disclosure

This change and this description were drafted with AI assistance (Claude Code, claude-opus-5), then reviewed by the submitting contributor. Disclosed per the Nextcloud AI Contribution Policy.

[artonge]

Makes sense, cc @icewind1991 and @bigcat88 as original author of those lines.

[artonge]

@printminion-co can you fix the AI policy trailer in your commit message?

[printminion-co]

@printminion-co can you fix the AI policy trailer in your commit message?

@artonge Looks like it is some permission issue on your side with

Run gh api "repos/nextcloud/server/issues/62694/labels" \
gh: Resource not accessible by integration (HTTP 403)
{"message":"Resource not accessible by integration","documentation_url":"https://docs.github.com/rest/issues/labels#add-labels-to-an-issue","sta

Per copilot analysis:

Fix
Update the "Label PR as AI assisted" step (line 141-151 in .github/workflows/ai-policy.yml) to use the --method POST flag correctly and ensure proper error handling:

Current code (lines 147-151):

YAML

gh api "repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/labels" \
  --method POST \
  -f "labels[]=AI assisted"
echo "Added 'AI assisted' label to PR #${{ github.event.pull_request.number }}"

Recommended fix:

YAML

gh pr edit "${{ github.event.pull_request.number }}" \
  --add-label "AI assisted" || echo "Warning: Could not add label (may already exist)"
echo "Added 'AI assisted' label to PR #${{ github.event.pull_request.number }}"

The gh pr edit command is the preferred method for adding labels to PRs and has better permission handling. Alternatively, ensure the token has proper scopes by verifying that secrets.COMMAND_BOT_PAT includes public_repo or repo scope with write:repository_hooks permissions.

[printminion-co]

/backport stable33

[printminion-co]

/backport to stable32

[printminion-co]

/backport to stable33

[AndyScherzinger]

/backport to stable34