Marketplace, Plugins, Extension Risks, and Compatibility Management: Diagnostics, Failure Modes, and Production Practices

1. Evidence-first diagnostic sequence

1. Preserve artifact URL, exact JAR, SHA-256/signature evidence, manifest, license/source record, and change ticket.
2. Preserve server version, Java/runtime, installed-plugin inventory, startup logs, and pre-change health.
3. Confirm current compatibility matrix and plugin release documentation.
4. Inspect whether the server reached UP after the deliberate restart.
5. If startup succeeded, inspect web/CE/scanner plugin-loading logs and the exact extension capability.
6. If an analysis ran, preserve scanner status, report-task.txt/ceTaskId, Compute Engine result, issues/measures/gate, and source revision.
7. In Data Center, compare plugin file names/checksums on every application node before any node returns to service.
8. Apply the least destructive correction: usually remove/replace only the newly introduced plugin artifact, then restart once and prove baseline recovery.

2. Failure: old tutorial recommends an abandoned plugin

The tutorial may be historically correct and operationally dangerous today. Check last release date, repository activity, issue tracker, current compatibility matrix, target Plugin API, and whether SonarQube now has a built-in or report-based alternative. An old release that “still downloads” is not evidence of support.

3. Failure: “Marketplace lists it, so Sonar guarantees it”

Current documentation explicitly states that third-party plugins are not provided by Sonar and are installed at the operator’s own risk. Marketplace/version-matrix compatibility is useful, but the governance record still needs publisher/source, license, exact bytes/digest, maintenance state, dependency evidence, and rollback.

4. Failure: floating plugin versions

A deployment manifest that installs latest or downloads a mutable release URL cannot reproduce the server. Two restarts on different days might fetch different bytes. Pin the version and artifact URL, store/verify the expected digest, and retain a copy or artifact-store reference allowed by the plugin license.

BROKEN
plugins.install=https://publisher.example/plugin/latest/plugin.jar

REPAIRED MODEL
plugin_version=1.2.3
artifact=plugin-1.2.3.jar
url=https://publisher.example/releases/1.2.3/plugin-1.2.3.jar
sha256=<verified digest>

5. Intentionally broken example: checksum mismatch

This is the safest failure to engineer because it stops before executable server state changes. Preserve both values:

EXPECTED_SHA256="$(printf '0%.0s' {1..64})"  # deliberately wrong for lab only
ACTUAL_SHA256="$(sha256sum "$PLUGIN_JAR" | awk '{print $1}')"
printf 'expected=%s\nactual=%s\n' "$EXPECTED_SHA256" "$ACTUAL_SHA256" \
  | tee evidence/checksum-failure.txt

test "$EXPECTED_SHA256" = "$ACTUAL_SHA256" || {
  echo "BLOCKED: artifact integrity mismatch" | tee -a evidence/checksum-failure.txt
  exit 42
}

Interpretation: either the expected digest is wrong/stale, the download location served different bytes, or the file changed/corrupted. The repair is to return to the canonical publisher/release source, verify the exact expected artifact and digest, and redownload. Never replace the gate with --no-check.

6. Failure: server does not return after plugin installation

Preserve the complete startup logs before changing anything. A representative incompatibility can present as a plugin deployment/class-loading exception:

INFO  web[...] Deploy plugin Example / 1.2.3
ERROR web[...] Fail to start web server
... plugin API / class loading / missing dependency evidence ...

Do not assume every startup failure is the plugin; compare with the baseline. If the failure appeared immediately after introducing one verified JAR and the logs name that extension/API/dependency, the least destructive rollback is:

# Preserve first-failure evidence first.
docker logs sq-ch26 > evidence/failed-startup.log 2>&1

# Remove only the introduced artifact.
docker exec sq-ch26 rm -f "/opt/sonarqube/extensions/plugins/$PLUGIN_JAR"
docker restart sq-ch26
curl -fsS http://localhost:9026/api/system/status \
  | tee evidence/recovered-status.json

If baseline recovery succeeds, compatibility/plugin packaging is the primary investigation layer. If it does not, continue down host/database/search/resource diagnostics while preserving the original plugin evidence.

7. Failure: transitive dependency or license was ignored

A plugin can carry bundled libraries that never appear in the plugin display name. For open-source artifacts, compare source/build metadata, inspect the JAR, and preserve any SBOM/dependency tree supplied by the project. If a legal/security review finds an unacceptable dependency, uninstall/replace the plugin; do not strip classes from the JAR by hand, because that creates an unmaintained artifact with unknown runtime behavior.

8. Failure: Data Center application nodes differ

A mixed plugin set can route requests/tasks through different code depending on which application node receives them. Current Data Center guidance therefore requires the plugin operation on every application node and all application nodes stopped during install/uninstall/upgrade. Search nodes are a different role and do not receive application plugins.

# Illustrative inventory only; run through your authorized cluster tooling.
for node in app1 app2 app3; do
  ssh "$node" 'sha256sum /opt/sonarqube/extensions/plugins/*.jar' \
    > "evidence/${node}-plugins.sha256"
done
# Compare exact key/version/digest sets before restart.

9. Failure: rollback artifact or baseline was lost

If you cannot reconstruct the previous plugin set, do not guess from filenames or a stale wiki. Recover from the approved artifact repository/change record/backups according to your operational process. The lesson’s preventive control is simple: preserve the pre-change inventory and exact approved plugin artifacts/digests before the change.

10. Causal layer map

11. Production shortcuts to reject

• Do not install an old plugin solely because a tutorial names it.
• Do not treat a Marketplace listing as a security endorsement.
• Do not use floating plugin versions or mutable download URLs.
• Do not delete logs before preserving the first failure.
• Do not remove the entire plugins directory because one extension fails.
• Do not edit SonarQube database/search state to “unregister” a plugin.
• Do not disable TLS verification to download artifacts.
• Do not downgrade SonarQube outside supported paths to keep an abandoned plugin.
• Do not install different JARs on Data Center application nodes.

Knowledge check

Official references and version notes

• Community Build — Installing a plugin — Marketplace/manual paths, compatible JAR requirement, extensions/plugins, Docker/Kubernetes guidance, restart and uninstall behavior.
• Community Build — Using Marketplace — installed/compatible plugin discovery, internet/proxy behavior, Administer System requirement, pending install/update/uninstall and restart.
• Community Build — Plugin version matrix — current plugin-to-Community-Build compatibility table.
• Community Build — Plugin basics — Plugin API, scanner/Compute Engine/web extension points, manifest metadata, dependencies and Plugin-RequiredForLanguages.
• Community Build — Performing the update — install compatible third-party plugins for the target release instead of blindly copying old plugin folders.
• SonarQube Server — Installing a plugin — current commercial manual-install model and Data Center application-node consistency/maintenance rules.
• Sonar Plugin API repository — independent Plugin API release stream and SonarQube ↔ Plugin API compatibility mappings.
• Official SonarQube Docker image tags — exact 26.9.0.129388-community image used by the checkpoint.