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
- 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.
- Remove the barrier entry if this executor type does not support it (barriers like "done" belong to the primary executor).
- Register the missing barrier function in the handlers map before calling GetCustomExecutor.
- 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
- Keep barrier names as named constants shared with handler registration keys.
- Never hardcode barrier strings in config; derive them from the handlers map you build.
- After tool renames, grep for the old barrier name across config and setup code.
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
- token validation disabled with default salt
- Token.CreationDisabled
- Internal
- failed to switch provider: %w
- knowledge: embedding provider is not configured
AI-assisted analysis of vxcontrol/pentagi@ea665308ba (2026-09-01).
Data as JSON: /api/errors/c0f57a5a1e54bf7f.
Report an issue: GitHub.