CronJob details and list crash when spec.suspend is not set (undefined)

[RobertSkawinski]

Describe the bug

Headlamp crashes with "Uh-oh! Something went wrong" when viewing CronJob details or the CronJob list if a CronJob does not have spec.suspend explicitly set in its manifest. Kubernetes defaults spec.suspend to false but does not always include it in the API response, causing undefined.toString() to throw a TypeError.

To Reproduce

1. Have a CronJob in the cluster that does not explicitly set spec.suspend (e.g. installed by a Helm chart that omits the field)
2. Navigate to Workloads → CronJobs
3. Click on the CronJob to open its details
4. UI crashes with "Uh-oh! Something went wrong"

Error from browser console

TypeError: can't access property "suspend", c.spec is undefined
HBe https://headlamp.poc1.swuppi.dev/assets/index-CE3nuifS.js:1167

Root cause

Three locations access spec.suspend without a null/undefined check:

frontend/src/components/cronjob/List.tsx:69

getValue: cronJob => cronJob.spec.suspend.toString(),
frontend/src/components/cronjob/Details.tsx:152


const isCronSuspended = cronJob?.spec.suspend;
frontend/src/components/cronjob/Details.tsx:241


value: item.spec.suspend.toString(),

When the Kubernetes API omits spec.suspend (which is valid — it defaults to false), these calls throw a TypeError because .toString() is called on undefined.

Suggested fix

Use nullish coalescing to default to false when the field is missing:

List.tsx:69


- getValue: cronJob => cronJob.spec.suspend.toString(),
+ getValue: cronJob => (cronJob.spec.suspend ?? false).toString(),
Details.tsx:152


- const isCronSuspended = cronJob?.spec.suspend;
+ const isCronSuspended = cronJob?.spec?.suspend ?? false;
Details.tsx:241


- value: item.spec.suspend.toString(),
+ value: (item.spec.suspend ?? false).toString(),

Environment

Installation type: In-cluster
Headlamp version: v0.41.0
Kubernetes version: 1.31
The bug also exists on main (checked 2026-04-07)

!! This code analysis has been done by AI: Claude - A developer is needed to verify if this change does not break something.

[RobertSkawinski]

Quick fix: patch the minified JS in the Deployment

If you're running Headlamp in-cluster, you can work around this by adding an init container to the Deployment that patches the frontend assets before Headlamp starts. This fixes all three crash locations without rebuilding the image.

Add a patch-frontend init container, an emptyDir volume, and mount it over /headlamp/frontend in the main container:

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "headlamp",
    "namespace": "headlamp"
  },
  "spec": {
    "template": {
      "spec": {
        "initContainers": [
          {
            "name": "patch-frontend",
            "image": "ghcr.io/headlamp-k8s/headlamp:v0.41.0",
            "command": ["sh", "-c", "cp -a /headlamp/frontend/* /patched-frontend/ && cd /patched-frontend/assets && sed -i -e 's/\\([a-zA-Z]\\)\\.spec\\.suspend\\.toString()/(\\1.spec.suspend!=null?\\1.spec.suspend.toString():\"false\")/g' -e 's/void 0:c\\.spec\\.suspend/void 0:c.spec\\&\\&c.spec.suspend/g' index-*.js && echo patched"],
            "volumeMounts": [
              { "name": "patched-frontend", "mountPath": "/patched-frontend" }
            ]
          }
        ],
        "containers": [
          {
            "name": "headlamp",
            "image": "ghcr.io/headlamp-k8s/headlamp:v0.41.0",
            "volumeMounts": [
              { "name": "patched-frontend", "mountPath": "/headlamp/frontend" }
            ]
          }
        ],
        "volumes": [
          { "name": "patched-frontend", "emptyDir": {} }
        ]
      }
    }
  }
}

What it does:

1. The init container uses the same Headlamp image to copy the original frontend assets to an emptyDir volume
2. Two sed expressions patch index-*.js:
   • Wraps .spec.suspend.toString() calls with a null check → (x.spec.suspend!=null?x.spec.suspend.toString():"false") (fixes List.tsx:69 and Details.tsx:241)
   • Guards c.spec.suspend where .spec itself can be undefined → c.spec&&c.spec.suspend (fixes Details.tsx:152)
3. The patched volume is mounted over /headlamp/frontend in the main container

Note: The browser console still logs the error from the WebSocket onMessage handler, but the UI no longer crashes.

Tested on v0.41.0.

[Athang69]

Verified the root cause manually. spec.suspend is indeed optional in the Kubernetes API spec batch/v1 CronJobSpec and legitimately absent from API responses when not explicitly set Kubernetes only serialises fields that differ from their zero value in some controllers/Helm-generated manifests.
Confirmed all three crash sites.
The fix is correct: ?? false matches the Kubernetes-defined default and is a no op when the field is present as true or false
No behaviour change for existing CronJobs.
/assign

[illume]

@RobertSkawinski
Patching the minified js to deploy... is genius. ❤️