[Lena Forlin (moshimorschi)]

What changed?

When a command stops because a dependency is missing, the command event now says so. Two tags are added to the existing shopware_cli.command event on such failures; no event name changes, so the telemetry pipeline's allow-list stays as it is.

• failure_category, with the value missing_prerequisite. It is the same word the Dev TUI install event already uses for its own failure categories, and it is the first value of the category the telemetry review ranks highest; later values go into the same tag.
• missing, a sorted, comma-separated list of what the dependency check found missing, with stable identifiers: docker_not_installed, docker_not_running, compose_plugin_missing, php_not_installed, php_version and other. The versions found or required are never sent.

To make that possible, each missing dependency now carries its identifier from the place where the check detects it, and the check's two reporting sites return a typed error with the list instead of a plain error. Commands that run the check: project create, project dev, and the proxy commands that need Docker.

One visible change: the explanation box on stderr used to be followed by a second line, ERROR missing required dependencies, because the root command logged the returned error again. Following the convention for errors that were already printed, the typed error is now on the root command's exemption list, so the box is the only output. The exit code stays 1.

Tags of the command event after this change, captured from the built binary with a local UDP listener, for project create --docker on a machine without Docker on the path:

{"command_name": "project.create", "result": "failure", "failure_category": "missing_prerequisite", "missing": "docker_not_installed", "cli_version": "dev"}

A failure for any other reason carries neither tag. docs/TELEMETRY.md documents both tags and the identifiers.

Why?

The dependency check already knew what was missing, but telemetry only recorded failure, so a machine without Docker looked like any other failed run. With the Compose plugin check from #1685, people without the plugin are stopped earlier, and without this change they would silently disappear from the data and the problem would look fixed. This keeps them visible, with the reason.

How was this tested?

• Unit tests: the existing dependency-check scenarios with a stubbed Docker now also assert the identifiers, a missing PHP binary yields php_not_installed, an unknown dependency falls back to other, the list is sorted and de-duplicated, the typed error survives wrapping, the tracker's tags on a wrapped missing-dependency error versus a plain failure, and the exit code test covers the silent exit.
• End to end: the built binary ran project create --docker with Docker absent from its search path. It stopped at the dependency box with no further error line, created no folder, exited 1, and sent the event shown above. The "not running" and Compose plugin cases go through the same code path and are covered by the unit tests; they were not forced on this machine.
• Lint reports no issues; the cmd, project, system and tracking packages pass.

Related issue or discussion

Part of the DX tools telemetry improvements. This branch is based on #1737, which introduced the tag map the tracker now extends; GitHub retargets this PR to main when that one is merged, and the branch will be rebased then so only this change remains in the diff.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}