sbom.enabled=true deploys the xray-sbom container but never adds jfxsbm to the router's required service types

[mkielar]

Chart: jfrog/xray (stable/xray)
Chart versions affected: 103.143.27 → 103.143.30, and current master (the relevant helper is identical across all of them)
Type: Bug

Summary

Enabling the SBOM microservice via sbom.enabled: true correctly renders the xray-sbom container into the Xray StatefulSet, and the service registers with the router at startup. However, the router's required-service-types list — JF_ROUTER_TOPOLOGY_LOCAL_REQUIREDSERVICETYPES, produced by the xray.router.requiredServiceTypes helper — is a hardcoded literal that does not include jfxsbm, regardless of sbom.enabled.

As a result the router logs a warning at registration and, on a router-only restart, silently drops the sbom service from its topology and does not re-register it (it only recovers on a full pod roll). There is no supported values-level way to fix this.

Steps to reproduce

helm template xray jfrog/xray --set sbom.enabled=true \
  | grep -E 'name: xray-sbom|JF_ROUTER_TOPOLOGY_LOCAL_REQUIREDSERVICETYPES' -A1

Observed output:

        - name: xray-sbom            # <-- container IS deployed
        ...
        - name: JF_ROUTER_TOPOLOGY_LOCAL_REQUIREDSERVICETYPES
          value: jfxr,jfxana,jfxidx,jfxpst,jfxpe,jfob     # <-- jfxsbm missing

Expected behavior

When sbom.enabled: true, the sbom service type (jfxsbm) should be included in JF_ROUTER_TOPOLOGY_LOCAL_REQUIREDSERVICETYPES (as it is a first-class service in the pod), so the router treats it as a required, restart-durable service — consistent with how the container itself is gated on sbom.enabled.

Actual behavior

jfxsbm is absent from the required set. At runtime the router logs (single-pod, splitXraytoSeparateDeployments.fullSplit=false):

[jfrou] [WARN ] [service_registry.go:78] - jfxsbm@<id> registered while it is not required
        ([jfxr jfxana jfxidx jfxpst jfxpe jfob]), this service will not be available
        in case of router restart

And it is accurate. Restarting only the router container (the other containers, including xray-sbom, keep running):

[jfrou] external_topology ... xray-0 removed (jfxsbm@<id>),
        state changed (jfob HEALTHY, jfxana HEALTHY, jfxidx HEALTHY, jfxpe HEALTHY, jfxpst HEALTHY, jfxr HEALTHY)

jfxsbm is removed from the topology and never re-registers on its own (verified over several minutes). The router then returns 404 for requests routed to the sbom service. Only a full pod restart re-registers it. (Async SBOM work off RabbitMQ continues; it is the router-fronted routing that is lost.)

Root cause

stable/xray/templates/_helpers.tpl:

{{- define "xray.router.requiredServiceTypes" -}}
{{- $requiredTypes := "jfxr,jfxana,jfxidx,jfxpst,jfxpe,jfob" -}}
{{- $requiredTypes -}}
{{- end -}}

The helper receives the root context (.) from the StatefulSet ({{ include "xray.router.requiredServiceTypes" . }}) but ignores it and emits a constant. It never consults .Values.sbom.enabled, so enabling sbom cannot influence the router's required-types string. (The xray.router.ipa.requiredServiceTypes variant has the same shape.)

Suggested fix

Make the helper conditionally append jfxsbm when the sbom service is enabled — mirroring the {{- if .Values.sbom.enabled }} gate already used for the container in xray-statefulset.yaml:

{{- define "xray.router.requiredServiceTypes" -}}
{{- $requiredTypes := "jfxr,jfxana,jfxidx,jfxpst,jfxpe,jfob" -}}
{{- if .Values.sbom.enabled -}}
{{- $requiredTypes = printf "%s,jfxsbm" $requiredTypes -}}
{{- end -}}
{{- $requiredTypes -}}
{{- end -}}

(If other optionally-enabled service types exist, the same pattern applies — the required-types list should be derived from the set of enabled services rather than a fixed literal.)

Workarounds attempted (and why they don't work)

• Override via router.extraEnvVars (re-declaring JF_ROUTER_TOPOLOGY_LOCAL_REQUIREDSERVICETYPES): the chart appends extraEnvVars after its own entry, producing a duplicate env key. helm upgrade (server-side apply) rejects it:
  failed to create typed patch object ... .spec.template.spec.containers[name="router"].env: duplicate entries for key [name="JF_ROUTER_TOPOLOGY_LOCAL_REQUIREDSERVICETYPES"]
• An "optional service types" router setting: none exists. The router's own startup config dump lists only requiredServiceTypes (no optionalServiceTypes).

So there is no clean way for a chart consumer to correct this without patching the chart. Hence this issue.

Environment

• Chart: jfrog/xray 103.143.27 (also confirmed on 103.143.30 and master)
• Xray appVersion 3.143.x
• Single-node Kubernetes; single-pod Xray (splitXraytoSeparateDeployments.fullSplit=false)
• sbom.enabled: true

[g3n35i5]

Possibly related, same theme (enabling sbom.enabled is under-wired), different mechanism — flagging in case it's worth a companion issue.

On a fresh jfrog-platform install with sbom.enabled: true, every Xray scan sat in "Scanning" in the UI forever and never produced results. Root cause turned out to be Xray runtime config, not a template: the SBOM PostScan worker pools default to 0 in the xrayConfig DB row (configuration table, under general_settings):

post_scan_workers = 0
post_scan_existing_content_workers = 0

At xray-sbom startup this surfaces as:

[jfxsb] [dispatcher] PostScanDispatcher.Start
[jfxsb] [WARN] PostScan New content Workers number is 0
[jfxsb] [WARN] PostScan Existing Content Workers number is 0

The usercatalog worker publishes results to the postScan exchange, but with zero PostScan workers nothing consumes it, so a scan's sca status source never reaches DONE and OverallStatus is stuck at SCANNING indefinitely (systemic — no artifact/build ever finalizes).

Fix was to set those keys non-zero directly in the DB and restart Xray:

UPDATE configuration SET config = convert_to(
  jsonb_set(jsonb_set(convert_from(config,'UTF8')::jsonb,
    '{general_settings,post_scan_workers}','8'::jsonb),
    '{general_settings,post_scan_existing_content_workers}','4'::jsonb)::text,'UTF8')
WHERE config_id='xrayConfig';

After a pod restart the PostScan dispatcher started 8 workers, the durable postScan backlog drained, and all previously-stuck scans finalized.

The relation to this issue: like the router requiredServiceTypes gap, flipping sbom.enabled: true is not sufficient to make SBOM fully functional, and there's no values-level way to set these worker counts (they're not in the chart, nor in any sizing/ example). It would help if the chart (or Xray itself on SBOM enablement) seeded the post_scan_* / sbom_cdxapi_* worker pools to non-zero defaults, or at least documented the requirement. Environment: chart jfrog-platform 11.5.6 (xray subchart 103.143.26), single node, splitServicesToContainers (non-fullSplit), external PostgreSQL, no JFrog Advanced Security entitlement.