Significant-Gravitas/AutoGPT · error · HTTPException

Expert #{expert_id} not found.

Error message

Expert #{expert_id} not found.

What it means

Schedule-creation raises 404 when an explicit schedule_params.expert_id fails `experts_db.get_expert(user_id, expert_id)`: either the expert row doesn't exist for this user or `expert.is_archived` is true. This is attribution validation — every schedule must map to an active expert owned by the caller; when expert_id is omitted the endpoint instead auto-resolves via resolve_expert_for_graph and never takes this branch.

Source

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

        )

    # Use timezone from request if provided, otherwise fetch from user profile
    if schedule_params.timezone:
        user_timezone = schedule_params.timezone
    else:
        user = await get_user_by_id(user_id)
        user_timezone = get_user_timezone_or_utc(user.timezone if user else None)

    # Expert attribution: explicit expert_id must be an active expert owned
    # by the caller; when omitted, a unique (user, graph) → expert match
    # keeps attribution for schedules created through the generic UI.
    expert_id = schedule_params.expert_id
    if expert_id is not None:
        expert = await experts_db.get_expert(
            user_id, expert_id, include_workflows=False
        )
        if expert is None or expert.is_archived:
            raise HTTPException(
                status_code=404, detail=f"Expert #{expert_id} not found."
            )
    else:
        expert_id = await experts_db.resolve_expert_for_graph(user_id, graph_id)

    result = await get_scheduler_client().add_execution_schedule(
        user_id=user_id,
        graph_id=graph_id,
        graph_version=graph.version,
        name=schedule_params.name,
        cron=schedule_params.cron,
        input_data=schedule_params.inputs,
        input_credentials=schedule_params.credentials,
        user_timezone=user_timezone,
        organization_id=ctx.org_id,
        team_id=ctx.team_id,
        expert_id=expert_id,
    )

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Re-fetch the caller's active experts and re-submit with a current, non-archived expert_id.
  2. Un-archive the expert if it should still receive attribution, or clear expert_id to let the endpoint auto-resolve the (user, graph) → expert match.
  3. Ensure the expert belongs to the same user_id that authenticated the request.

Example fix

// before
await api.createSchedule({graphId, expertId: savedExpertId, ...});
// after — drop stale expert ids
const experts = await api.listExperts({archived: false});
const expert = experts.find(e => e.id === savedExpertId);
await api.createSchedule({graphId, expertId: expert?.id ?? undefined, ...});
Defensive patterns

Strategy: validation

Validate before calling

const experts = await api.listExperts();
const active = experts.filter(e => !e.isArchived && e.userId === currentUserId);
const expertId = active.some(e => e.id === pickedId) ? pickedId : undefined;

Type guard

function isActiveOwnedExpert(e: ExpertDTO | undefined, userId: string): boolean {
  return !!e && e.userId === userId && !e.isArchived;
}

Try / catch

try {
  await api.createSchedule({...params, expertId});
} catch (e) {
  if (e.status === 404 && 'expert_id' in payload) {
    // re-fetch active experts and retry once without the stale id
    return api.createSchedule({...payload, expertId: undefined});
  }
  throw e;
}

Prevention

When it happens

Trigger: POST /v1/schedules with expert_id in the body that is deleted/archived, belongs to another user, or is a stale ID kept in frontend state after the expert list changed.

Common situations: UI caching an expert picker selection after the expert was archived; scheduling from a saved form/config that pins an old expert_id; API scripts reusing expert IDs across accounts.

Related errors


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