vxcontrol/pentagi · error

failed to parse get_flow_status args: %w

Error message

failed to parse get_flow_status args: %w

What it means

The get_flow_status tool unmarshals its JSON arguments into GetFlowStatusAction before dispatching. If args is not valid JSON or does not match the expected struct (wrong types, malformed syntax), the tool returns this wrapped parse error. It is a tool-input contract failure, not a flow-state problem.

Source

Thrown at backend/pkg/tools/flow_manager.go:70

	taskReadyPollTimeout   = 2 * time.Minute
	waitFlowDefaultTimeout = 1 * time.Minute
	waitFlowMaxTimeout     = 1 * time.Hour
	msgLogsLimit           = 16 * 1024  // 16 KB
	summaryLimit           = 32 * 1024  // 32 KB
	taskListLimit          = 32 * 1024  // 32 KB
	subtasksListLimit      = 48 * 1024  // 48 KB
	plannedListLimit       = 32 * 1024  // 32 KB
	runningInfoLimit       = 48 * 1024  // 48 KB
	inputLimit             = 8 * 1024   // 8 KB
	descriptionLimit       = 4 * 1024   // 4 KB
	resultLimit            = 8 * 1024   // 8 KB
	summarizationLimit     = 128 * 1024 // 128 KB hard limit
)

func (t *flowStatusTool) Handle(ctx context.Context, name string, args json.RawMessage) (string, error) {
	var action GetFlowStatusAction
	if err := json.Unmarshal(args, &action); err != nil {
		return "", fmt.Errorf("failed to parse get_flow_status args: %w", err)
	}

	verbose := action.Verbose.Bool()

	switch action.Detail {
	case FlowStatusDetailSummary:
		return t.buildSummary(ctx, verbose)
	case FlowStatusDetailTasks:
		return t.buildTasksList(ctx, verbose)
	case FlowStatusDetailSubtasks:
		return t.buildSubtasksList(ctx, action.TaskID.PtrInt64(), verbose)
	case FlowStatusDetailRunning:
		return t.buildRunningInfo(ctx, verbose)
	case FlowStatusDetailPlanned:
		return t.buildPlannedList(ctx, action.TaskID.PtrInt64(), verbose)
	default:
		return "", fmt.Errorf("unknown detail level %q; use one of: summary, tasks, subtasks, running, planned", action.Detail)
	}

View on GitHub (pinned to ea665308ba)

Solutions

  1. Validate the args JSON with a parser (jq) and fix the syntax error indicated by the wrapped message.
  2. Ensure 'detail' is a string: one of summary, tasks, subtasks, running, planned.
  3. Omit optional fields rather than sending them with wrong types (e.g. verbose must be boolean).
  4. If an LLM generates the args, tighten the tool's JSON schema / prompt examples for get_flow_status.

Example fix

// before
{"detail": summary, "verbose": "true"}

// after
{"detail": "summary", "verbose": true}
Defensive patterns

Strategy: validation

Validate before calling

func validGetFlowStatusArgs(raw json.RawMessage) error {
	if !json.Valid(raw) { return errors.New("args is not valid JSON") }
	var probe struct {
		Detail  *string `json:"detail"`
		Verbose *bool   `json:"verbose"`
	}
	if err := json.Unmarshal(raw, &probe); err != nil { return err }
	return nil
}

Type guard

func isValidFlowStatusArgs(raw json.RawMessage) bool {
	var action GetFlowStatusAction
	return json.Unmarshal(raw, &action) == nil
}

Try / catch

out, err := tool.Handle(ctx, "get_flow_status", args)
if err != nil {
	var parseErr *json.SyntaxTypeError
	if errors.As(err, &parseErr) {
		// re-serialize args strictly with encoding/json before retrying
	}
	return err
}

Prevention

When it happens

Trigger: Tool called with args like '{detail:}' (invalid JSON), '{"detail": 123}' (type mismatch — Detail is a string enum), or a JSON array/string where an object was expected.

Common situations: LLM tool-caller emits single-quoted or unquoted JSON; caller passes the detail value as a number; argument serialization bug upstream producing empty or truncated JSON; nested quotes not escaped properly.

Understand the failure class

Related errors


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