Significant-Gravitas/AutoGPT · error · NotFoundError

Transfer request {transfer_id} not found

Error message

Transfer request {transfer_id} not found

What it means

NotFoundError from approve_transfer_request() when prisma.transferrequest.find_unique(transfer_id) returns None: the transfer being approved does not exist (deleted, expired/cleaned up, wrong ID, or wrong environment). Distinct from the later ValueError branches that fire when the transfer exists but is in a terminal state.

Source

Thrown at autogpt_platform/backend/backend/api/features/transfers/db.py:88

        order={"createdAt": "desc"},
    )
    return [TransferResponse.from_db(t) for t in transfers]


async def approve_transfer(
    transfer_id: str,
    user_id: str,
    org_id: str,
) -> TransferResponse:
    """Approve a transfer from the source or target side.

    - If user's active org is the source org, sets sourceApprovedByUserId.
    - If user's active org is the target org, sets targetApprovedByUserId.
    - Advances the status accordingly.
    """
    tr = await prisma.transferrequest.find_unique(where={"id": transfer_id})
    if tr is None:
        raise NotFoundError(f"Transfer request {transfer_id} not found")

    if tr.status in ("COMPLETED", "REJECTED"):
        raise ValueError(f"Cannot approve a transfer with status '{tr.status}'")

    update_data: dict = {}

    if org_id == tr.sourceOrganizationId:
        if tr.sourceApprovedByUserId is not None:
            raise ValueError("Source organization has already approved this transfer")
        update_data["sourceApprovedByUserId"] = user_id
        if tr.targetApprovedByUserId is not None:
            # Both sides approved — ready for execution (NOT completed yet)
            update_data["status"] = "TARGET_APPROVED"
        else:
            update_data["status"] = "SOURCE_APPROVED"

    elif org_id == tr.targetOrganizationId:
        if tr.targetApprovedByUserId is not None:

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Re-fetch the user's pending transfers and confirm the ID still exists before approving.
  2. If the transfer was cancelled/completed and removed, discard the stale notification/link.
  3. Verify environment alignment (client pointed at the API that owns the transfer record).
Defensive patterns

Strategy: validation

Validate before calling

tr = await prisma.transferrequest.find_unique(where={"id": transfer_id})
transfer_approvable = tr is not None and tr.status not in ("COMPLETED", "REJECTED")

Try / catch

try:
    resp = await approve_transfer_request(transfer_id, user_id, org_id)
except NotFoundError:
    discard_stale_notification(transfer_id)
    raise HTTPException(404, "Transfer no longer exists")

Prevention

When it happens

Trigger: Calling approve on a transfer ID from a stale notification/email link after the request was cancelled or removed, a typo'd ID, or a transfer created in a different database/environment.

Common situations: Approver opens an old email after the initiator cancelled; two approvers acting and one flow deleting the request; test suites referencing transfers created in a prior run.

Related errors


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