Significant-Gravitas/AutoGPT · error · DatabaseError

Failed to fetch store agents

Error message

Failed to fetch store agents

What it means

A DatabaseError raised by the store listing query (get_store_agents) when any exception escapes the Prisma query / response-building path for the paginated store agents list. The original cause is chained ('from e') and logged as 'Error getting store agents'; the user-facing message is a generic fetch failure.

Source

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

                sorted_by=sorted_by,
                page=page,
                page_size=page_size,
            )
            total_pages = (total + page_size - 1) // page_size

        logger.debug(f"Found {len(store_agents)} agents")
        return store_model.StoreAgentsResponse(
            agents=store_agents,
            pagination=store_model.Pagination(
                current_page=page,
                total_items=total,
                total_pages=total_pages,
                page_size=page_size,
            ),
        )
    except Exception as e:
        logger.error(f"Error getting store agents: {e}")
        raise DatabaseError("Failed to fetch store agents") from e
    # TODO: commenting this out as we concerned about potential db load issues
    # finally:
    #     if search_term:
    #         await log_search_term(search_query=search_term)


async def _fallback_store_agent_search(
    *,
    search_query: str | None,
    featured: bool,
    creators: list[str] | None,
    category: str | None,
    sorted_by: StoreAgentsSortOptions | None,
    page: int,
    page_size: int,
) -> tuple[list[store_model.StoreAgent], int]:
    """Direct DB search fallback when hybrid search is unavailable or empty.

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Check backend logs for 'Error getting store agents' — the chained exception has the true cause.
  2. If it's a schema/client mismatch, run database migrations and regenerate the Prisma client, then restart.
  3. Verify DB connectivity and pool health from the backend host.
  4. Sanitize/validate pagination and filter parameters before they reach the query.

Example fix

# before
# schema.prisma updated but client stale -> Unknown column errors
# after
poetry run prisma generate && poetry run prisma db push && restart backend
Defensive patterns

Strategy: retry

Validate before calling

// Validate pagination inputs before listing
if (!(page >= 1) || !(page_size >= 1 && page_size <= 100)) {
  throw new RangeError('page must be >=1 and page_size in [1,100]');
}

Type guard

const isValidPagination = (p: unknown) =>
  typeof p === 'number' && Number.isInteger(p) && p >= 1;

Try / catch

try { return await getStoreAgents(filters); }
catch (e) {
  if (e instanceof DatabaseError && /fetch store agents/.test(e.message)) {
    return await withBackoff(() => getStoreAgents(filters), { tries: 2 }); // transient DB issues
  }
  throw e;
}

Prevention

When it happens

Trigger: GET store agents endpoints while the database is unreachable, the Prisma client is out of date with the schema (unknown column/relation), a pagination parameter causes an invalid query, or response model construction fails on unexpected nulls.

Common situations: DB outage or connection pool exhaustion; migrations run but prisma client not regenerated; schema drift between environments; malformed query params (negative page) reaching the ORM and erroring.

Related errors


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