conductor-oss/conductor · error · SafeConditionParseException

condition exceeds 1024 characters

Error message

condition exceeds 1024 characters

What it means

SafeConditionInterpreter.parse throws when the condition string exceeds MAX_LENGTH (1024 characters). The cap exists to bound parse/eval work and to keep plan-supplied expressions auditable; an over-long expression usually indicates a generated or malformed payload rather than a hand-authored one.

Source

Thrown at agentspan/src/main/java/org/conductoross/conductor/ai/agentspan/runtime/util/SafeConditionInterpreter.java:80

 *
 * <p>If those ever need to be supported, extending the grammar requires adding a new node type with
 * a {@link Node#eval(Map)} implementation — the addition is auditable in code review rather than
 * silently re-opened by widening a regex.
 */
public final class SafeConditionInterpreter {

    private SafeConditionInterpreter() {}

    /** Maximum source length accepted by the parser. */
    public static final int MAX_LENGTH = 1024;

    // ── Public API ─────────────────────────────────────────────────

    /** Parse a condition into an AST. Throws on syntax errors. */
    public static Node parse(String src) {
        if (src == null) throw new SafeConditionParseException("null condition");
        if (src.length() > MAX_LENGTH) {
            throw new SafeConditionParseException(
                    "condition exceeds " + MAX_LENGTH + " characters");
        }
        Parser p = new Parser(src);
        Node ast = p.parseExpr();
        p.expectEnd();
        return ast;
    }

    /** Evaluate the parsed condition against a root map. */
    public static boolean evaluate(String src, Map<String, Object> root) {
        return truthy(parse(src).eval(root != null ? root : Map.of()));
    }

    /** True if and only if {@link #parse(String)} would accept this string. */
    public static boolean isSafe(String src) {
        try {
            parse(src);
            return true;

View on GitHub (pinned to cf7c3e4a8a)

Solutions

  1. Shorten the condition: reference fields from the root map (`$.foo`) instead of inlining large literals.
  2. Split into multiple shorter conditions evaluated separately and combined in Java.
  3. If a genuine long condition is required, raise MAX_LENGTH in the source after reviewing the security/perf implications.

Example fix

// before: inlined JSON literal as condition, >1024 chars
String cond = "$.data == '{\"huge\":\"json\",...}'";
// after: compare a field extracted into the root map
String cond = "$.data.huge == 'json'";
Defensive patterns

Strategy: validation

Validate before calling

if (condition.length() > SafeConditionInterpreter.MAX_LENGTH) {
    throw new IllegalArgumentException(
        "condition exceeds " + SafeConditionInterpreter.MAX_LENGTH + " characters");
}

Type guard

boolean isWithinLengthLimit(String s) {
    return s != null && s.length() <= SafeConditionInterpreter.MAX_LENGTH;
}

Try / catch

try { return SafeConditionInterpreter.parse(condition); }
catch (SafeConditionParseException e) {
    if (e.getMessage().contains("exceeds")) return badRequest(e.getMessage());
    throw e;
}

Prevention

When it happens

Trigger: Passing a success_condition longer than 1024 chars to parse()/evaluate() — e.g. a giant inlined JSON literal, a base64 blob, or an accidentally-concatenated multi-condition string.

Common situations: A generator inlined a whole document as the condition; a copy-paste concatenated several conditions without operators; a templating bug produced a runaway string.

Related errors


AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14). Data as JSON: /api/errors/09094f6b427d8aba. Report an issue: GitHub.