Skip to content

Task without spec crashes the controller with a nil-pointer panic #349

Open

Description

@fkautz

Problem

The API accepts a Task with no spec, but the controller dereferences task.Spec.Gateway before initializing the spec. Processing that task panics and terminates the controller process.

Reproduction

Apply a metadata-only Task:

apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: no-spec

ValidateTask accepts the missing spec. When the worker processes the resulting event, it panics at internal/controller/worker.go:131.

Expected behavior

Either reject the task at the API boundary with a validation error or initialize an empty spec before accessing its fields. An accepted task must not crash the controller.

Observed behavior

A local regression test submits the task through Server.UpdateTask, then processes it through Worker.Run:

API accepted metadata-only Task, then Worker.Run panicked:
runtime error: invalid memory address or nil pointer dereference

Test: TestReviewMissingSpecDoesNotCrashWorker

The test uses the production API and worker with an in-memory store and an in-process Substrate fake. The panic occurs before any Substrate RPC. The test source and its supporting fixture are published in the fork linked below.

Impact

One accepted metadata-only task can terminate a controller worker, interrupting reconciliation of other tasks.

Published regression test

TestReviewMissingSpecDoesNotCrashWorker. Supporting fixtures are in the same file and the repository's existing controller tests.

git clone --branch test/review-regressions https://github.com/fkautz/ax.git ax-review
cd ax-review
git checkout 1dc2613d29e12f306154a7e1183c1825a55d24ed
go test ./internal/controller -run '^TestReviewMissingSpecDoesNotCrashWorker$' -count=1 -v

Requires the Go toolchain specified in go.mod. No cluster or Redis instance is required. The test asserts no panic and fails on this revision. Panic recovery exists only in the test harness. Production code is unchanged.

Activity

  1. Ashfaqbs commented on Sep 21, 2026

    @Ashfaqbs

    I ran into the same panic and have a fix ready, but gh pr create against this repo is returning a permissions error for my account (Ashfaqbs does not have the correct permissions to execute CreatePullRequest), so I can't open the PR directly right now.

    Fix

    Worker.processEvent in internal/controller/worker.go dereferenced task.Spec.Gateway.Name directly (line 131) without checking whether task.Spec itself was nil. Since ValidateTask deliberately accepts a Task with no spec (it returns nil/no-error early on a nil spec), a metadata-only Task passes validation and then crashes the worker as soon as it's processed.

    Replaced the raw field-chain access with the chain of nil-safe generated getters already used elsewhere in this codebase:

    var gw *v1alpha1.Gateway
    if gwRef := task.GetSpec().GetGateway(); gwRef.GetName() != "" {
        g, err := w.store.GetGateway(ctx, task.Metadata.Atespace, gwRef.GetName())
        ...
    }

    This matches the same nil-safety idiom the file already uses for task.Spec.WorkspaceRefs() and that ValidateTask relies on.

    Testing

    • Added a regression test (TestWorkerMissingSpecDoesNotPanic) that saves a metadata-only Task and asserts the worker reaches a terminal phase instead of crashing.
    • Verified it reproduces the exact panic from this issue (worker.go:131, nil pointer dereference) against the unfixed code, then passes with the fix applied.
    • go test ./internal/controller/... passes with no regressions.

    Branch is pushed and ready: https://github.com/Ashfaqbs/ax/compare/main...Ashfaqbs:ax:fix/worker-nil-spec-panic?expand=1

    I'm happy to open the PR myself as soon as I have the right permissions - just let me know if there's something I need to do on my end (e.g. CLA), or if a maintainer needs to grant access first.

  2. arbazkhan971 commented on Sep 22, 2026

    @arbazkhan971

    Fix ready: implemented on my fork (branch fix/349-nil-spec-panic, regression test included, make test green) and ready to PR — but this repo's collaborators_only PR creation policy rejects PRs from non-collaborators (see #358), so I cannot open it. If PR creation opens for external contributors, I will open the PR immediately. Happy to adjust scope per maintainer feedback.

  3. self-assigned this
    on Sep 25, 2026
  4. rakyll commented on Sep 25, 2026

    @rakyll
    Member

    @fkautz you should be able to open a PR to send a fix now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions