netbirdio/netbird · warning

job not implemented

Error message

job not implemented

What it means

Sentinel ErrJobNotImplemented (client/jobexec/executor.go:21). The agent receives management-initiated jobs on a stream (Engine.receiveJobEvents in client/internal/engine.go); only the Bundle job workload type is handled, and any other WorkloadParameters hits the default case, which answers the job with status failed and this message as the Reason. It marks a job type the agent build does not support, typically a management server newer than the agent.

Source

Thrown at client/jobexec/executor.go:21

import (
	"context"
	"errors"
	"fmt"
	"os"
	"time"

	log "github.com/sirupsen/logrus"

	"github.com/netbirdio/netbird/client/internal/debug"
	"github.com/netbirdio/netbird/upload-server/types"
)

const (
	MaxBundleWaitTime = 60 * time.Minute // maximum wait time for bundle generation (1 hour)
)

var (
	ErrJobNotImplemented = errors.New("job not implemented")
)

type Executor struct {
}

func NewExecutor() *Executor {
	return &Executor{}
}

func (e *Executor) BundleJob(ctx context.Context, debugBundleDependencies debug.GeneratorDependencies, params debug.BundleConfig, waitForDuration time.Duration, mgmURL string) (string, error) {
	if waitForDuration > MaxBundleWaitTime {
		log.Warnf("bundle wait time %v exceeds maximum %v, capping to maximum", waitForDuration, MaxBundleWaitTime)
		waitForDuration = MaxBundleWaitTime
	}

	if waitForDuration > 0 {
		if err := waitFor(ctx, waitForDuration); err != nil {
			return "", err

View on GitHub (pinned to 93e97f4bf1)

Solutions

1. Update the agent to a release that supports the job type management is dispatching.
2. On the management side, restrict dispatch of new job kinds to peers whose agent version supports them.
3. Treat the failed-job reason as informational: the connection itself is unaffected.

Example fix

// before: management dispatches an unsupported workload to any peer
job := &mgmProto.JobRequest{WorkloadParameters: &mgmProto.JobRequest_Metrics{}}

// after: gate new job kinds on agent capability/version
if !peerSupportsJob(peer, mgmProto.JobRequest_METRICS) {
    return fmt.Errorf("peer %s cannot run this job (job not implemented)", peer.ID)
}

// Management-side: only dispatch job kinds the peer's agent supports.
if !agentSupportsWorkload(peer.AgentVersion, requestedWorkload) {
    return fmt.Errorf("skip job: peer agent does not implement workload %T", requestedWorkload)
}

func isJobNotImplemented(reason string) bool {
    return strings.Contains(reason, jobexec.ErrJobNotImplemented.Error())
}

// Job reasons arrive as strings in the JobResponse; inspect Reason on failed jobs.
if resp.GetStatus() == mgmProto.JobStatus_failed && isJobNotImplemented(string(resp.GetReason())) {
    // agent too old for this job kind: upgrade the agent or stop dispatching it
}

When it happens

Trigger: Management dispatches a JobRequest whose WorkloadParameters is not *mgmProto.JobRequest_Bundle (e.g. a new job kind introduced in a newer management release) to an older agent; test harnesses sending synthetic job types.

Common situations: Management upgraded before the agents: new job kinds fail on fleet agents still on older versions, showing 'job not implemented' as the failure reason in management. The job stream keeps running; only that job is rejected.

Related errors

• management client is not initialised
• service name is required
• service name exceeds maximum length of 255 characters
• at least one target is required
• private services require at least one access group

AI-assisted analysis of netbirdio/netbird@93e97f4bf1 (2026-08-16). Data as JSON: /api/errors/58b8f5f3a3102667. Report an issue: GitHub.