Significant-Gravitas/AutoGPT · error · ValueError

Transaction count limit must be between 1 and 1000

Error message

Transaction count limit must be between 1 and 1000

What it means

A bare `raise ValueError(...)` inside the get_credit_history async route when transaction_count_limit is outside [1, 1000]. Unlike every other check in this file it is NOT an HTTPException, so FastAPI's generic exception handler converts it into an unlogged 500 Internal Server Error rather than a 422 — the client sees a server bug, not a validation message.

Source

Thrown at autogpt_platform/backend/backend/api/features/v1.py:1578

    credit_model = await get_credit_model(user_id, ctx.org_id)
    return {"url": await credit_model.create_billing_portal_session(user_id)}


@v1_router.get(
    path="/credits/transactions",
    tags=["credits"],
    summary="Get credit history",
    dependencies=[Security(requires_user)],
)
async def get_credit_history(
    user_id: Annotated[str, Security(get_user_id)],
    ctx: Annotated[RequestContext, Security(get_request_context)],
    transaction_time: datetime | None = None,
    transaction_type: str | None = None,
    transaction_count_limit: int = 100,
) -> TransactionHistory:
    if transaction_count_limit < 1 or transaction_count_limit > 1000:
        raise ValueError("Transaction count limit must be between 1 and 1000")

    credit_model = await get_credit_model(user_id, ctx.org_id)
    return await credit_model.get_transaction_history(
        user_id=user_id,
        transaction_time_ceiling=transaction_time,
        transaction_count_limit=transaction_count_limit,
        transaction_type=transaction_type,
    )


@v1_router.get(
    path="/credits/refunds",
    tags=["credits"],
    summary="Get refund requests",
    dependencies=[Security(requires_user)],
)
async def get_refund_requests(
    user_id: Annotated[str, Security(get_user_id)],

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Clamp the request to 1 <= transaction_count_limit <= 1000 (paginate with transaction_time cursor for more rows).
  2. Fix the endpoint: replace the bare ValueError with FastAPI Query constraints — `transaction_count_limit: Annotated[int, Query(ge=1, le=1000)] = 100` — so clients get a proper 422.
  3. At minimum change the raise to HTTPException(status_code=422, detail=...) to match the file's conventions.

Example fix

# before
    transaction_count_limit: int = 100,
) -> TransactionHistory:
    if transaction_count_limit < 1 or transaction_count_limit > 1000:
        raise ValueError("Transaction count limit must be between 1 and 1000")

# after
    transaction_count_limit: Annotated[int, Query(ge=1, le=1000)] = 100,
) -> TransactionHistory:
    ...
Defensive patterns

Strategy: validation

Validate before calling

const limit = Math.min(Math.max(requestedLimit, 1), 1000);
await api.getCreditHistory({ transaction_count_limit: limit });

Type guard

const isValidLimit = (n: number) => Number.isInteger(n) && n >= 1 && n <= 1000;

Try / catch

catch (e) { if (e.response?.status === 500 && limitParamOutOfRange) { clampLimitAndRetry(); } else throw e; } // note: server currently returns 500, not 422

Prevention

When it happens

Trigger: GET /credits with transaction_count_limit=0, a negative value, or >1000 (e.g. a dashboard 'load all history' button passing 10000). The response is a 500 with a generic 'Internal Server Error' detail.

Common situations: Frontends paginating credit history and computing limits dynamically (total count > 1000); API consumers assuming uncapped limits; the 500 masking the real cause so devs hunt for server faults instead of their query param.

Related errors


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