vxcontrol/pentagi · error

barrier function %s not found

Error message

barrier function %s not found

What it means

flowToolsExecutor validates that every barrier function name listed in cfg.Barriers exists in its registered tool handlers map (fte.handlers). Barriers are special flow-control functions (e.g. task done markers) that must be backed by a registered handler. If a configured barrier name has no matching handler, executor construction is aborted with this error.

Source

Thrown at backend/pkg/tools/tools.go:794

	for _, def := range cfg.Definitions {
		if _, ok := cfg.Handlers[def.Name]; !ok {
			return nil, fmt.Errorf("handler for function %s not found", def.Name)
		}
	}

	for _, builtin := range cfg.Builtin {
		if def, ok := fte.definitions[builtin]; !ok {
			return nil, fmt.Errorf("builtin function %s not found", builtin)
		} else {
			cfg.Definitions = append(cfg.Definitions, def)
			cfg.Handlers[builtin] = fte.handlers[builtin]
		}
	}

	barriers := make(map[string]struct{})
	for _, barrier := range cfg.Barriers {
		if _, ok := fte.handlers[barrier]; !ok {
			return nil, fmt.Errorf("barrier function %s not found", barrier)
		}
		barriers[barrier] = struct{}{}
	}

	return &customExecutor{
		userID:      fte.userID,
		flowID:      fte.flowID,
		taskID:      cfg.TaskID,
		subtaskID:   cfg.SubtaskID,
		mlp:         fte.mlp,
		tclp:        fte.tclp,
		vslp:        fte.vslp,
		db:          fte.db,
		store:       fte.store,
		definitions: cfg.Definitions,
		handlers:    cfg.Handlers,
		barriers:    barriers,
		summarizer:  cfg.Summarizer,

View on GitHub (pinned to ea665308ba)

Solutions

  1. Check the barrier names in cfg.Barriers against the keys registered in fte.handlers for the executor type you are constructing and fix typos/renames.
  2. Remove the barrier entry if this executor type does not support it (barriers like "done" belong to the primary executor).
  3. Register the missing barrier function in the handlers map before calling GetCustomExecutor.
  4. If a recent upgrade caused it, compare old and new barrier/tool names in the providers/executor setup code.

Example fix

// before
executor, err := fte.GetCustomExecutor(CustomExecutorConfig{
  Handlers: map[string]FunctionHandler{"task_done": h},
  Barriers: []string{"done"}, // wrong: not in handlers
})
// after
executor, err := fte.GetCustomExecutor(CustomExecutorConfig{
  Handlers: map[string]FunctionHandler{"task_done": h},
  Barriers: []string{"task_done"}, // must match a registered handler
})
Defensive patterns

Strategy: validation

Validate before calling

registered := map[string]struct{}{"task_done": {}, "done": {}} // mirror of handlers known to be registered
for _, b := range cfg.Barriers {
    if _, ok := registered[b]; !ok {
        return fmt.Errorf("unknown barrier %q", b)
    }
}

Try / catch

executor, err := fte.GetCustomExecutor(cfg)
if err != nil {
    if strings.Contains(err.Error(), "barrier function") {
        // log cfg.Barriers and the registered handler keys, fail fast
    }
    return err
}

Prevention

When it happens

Trigger: Calling GetCustomExecutor (or a similar constructor path that loops over cfg.Barriers) with a Barriers slice containing a name that was never registered in the tool executor's handlers map — typically a typo, a renamed tool, or a barrier name only registered by a different executor type (e.g. GetPrimaryExecutor registers "done" but GetCustomExecutor does not).

Common situations: Copy-pasting executor config between flow types; upgrading PentAGI where a barrier/tool was renamed; hand-writing config with a misspelled barrier string; passing barrier names valid for the primary executor into a custom executor.

Related errors


AI-assisted analysis of vxcontrol/pentagi@ea665308ba (2026-09-01). Data as JSON: /api/errors/c0f57a5a1e54bf7f. Report an issue: GitHub.