Significant-Gravitas/AutoGPT · warning · DatabaseError

Invalid search query

Error message

Invalid search query

What it means

Raised in get_store_creators when a search_query is supplied but is empty after stripping whitespace or longer than 100 characters. Despite being raised as DatabaseError, this is purely input validation on the creators search endpoint — no database call has been made yet. The query is then escaped (%, _, quotes, comment markers) before being used in Prisma 'contains' filters.

Source

Thrown at autogpt_platform/backend/backend/api/features/store/db.py:504

        "Getting store creators: "
        f"featured={featured}, query={search_query}, sorted_by={sorted_by}, page={page}"
    )

    # Build where clause with sanitized inputs
    where = {}

    # Only return creators with approved agents
    where["num_agents"] = {"gt": 0}

    if featured:
        where["is_featured"] = featured

    # Add search filter if provided, using parameterized queries
    if search_query:
        # Sanitize and validate search query by escaping special characters
        sanitized_query = search_query.strip()
        if not sanitized_query or len(sanitized_query) > 100:  # Reasonable length limit
            raise DatabaseError("Invalid search query")

        # Escape special SQL characters
        sanitized_query = (
            sanitized_query.replace("\\", "\\\\")
            .replace("%", "\\%")
            .replace("_", "\\_")
            .replace("[", "\\[")
            .replace("]", "\\]")
            .replace("'", "\\'")
            .replace('"', '\\"')
            .replace(";", "\\;")
            .replace("--", "\\--")
            .replace("/*", "\\/*")
            .replace("*/", "\\*/")
        )

        where["OR"] = [
            {"username": {"contains": sanitized_query, "mode": "insensitive"}},

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Trim the query client-side and skip the request when the result is empty.
  2. Enforce a maxlength=100 on the search input element.
  3. If long queries are legitimate, chunk or truncate them before sending instead of letting the server reject.

Example fix

// before
const res = await fetch(`/store/creators?search=${raw}`);
// after
const q = raw.trim().slice(0, 100);
if (q) { const res = await fetch(`/store/creators?search=${encodeURIComponent(q)}`); }
Defensive patterns

Strategy: validation

Validate before calling

const q = (searchInput ?? '').trim();
if (q.length === 0 || q.length > 100) {
  // skip the request or show 'query too long' instead of calling the API
  return;
}
const res = await fetch(`/store/creators?search=${encodeURIComponent(q)}`);

Type guard

function isValidCreatorSearch(q: string | null | undefined): boolean {
  const s = (q ?? '').trim();
  return s.length > 0 && s.length <= 100;
}

Prevention

When it happens

Trigger: GET /store/creators?search=%20 (whitespace-only), or a search string longer than 100 characters, e.g. a client concatenating user input or pasting a long blob into the search box.

Common situations: Frontend search box submitted before debounce/trim; a URL builder appending an untrimmed query param; automated scrapers or fuzzers sending long payloads; copy-paste of text with trailing newlines.

Related errors


AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14). Data as JSON: /api/errors/e47eb43796a8ea26. Report an issue: GitHub.