iflytek/astron-agent · warning · BusinessException

67011

67011

Error message

permission.bot.belong.wrong.user

What it means

BotPermissionUtil.checkBot(botId) verifies that the bot exists and belongs to the current user (when no space context) or to the current space (when spaceId is present). If chatBotBaseMapper.exists(query) finds no matching row, it throws BusinessException with PERMISSION_BOT_NOT_BELONG_USER (message 'permission.bot.belong.wrong.user', code 67011) for the personal case, or PERMISSION_BOT_NOT_BELONG_SPACE for the space case. This is an authorization guard, not a data error.

Solutions

  1. Verify the request carries the correct space context headers so SpaceInfoUtil.getSpaceId() resolves to the bot's actual space
  2. Confirm the botId exists in chat_bot_base and its uid/space_id match the requesting user/space
  3. Refresh the frontend bot list to eliminate stale botIds after deletion or space migration
  4. Handle BusinessException code 67011 in the caller with a friendly 'no permission for this bot' message instead of treating it as a system failure

Example fix

// before
botPermissionUtil.checkBot(request.getBotId()); // throws 67011 for foreign bots
// after
try {
    botPermissionUtil.checkBot(request.getBotId());
} catch (BusinessException e) {
    if (ResponseEnum.PERMISSION_BOT_NOT_BELONG_USER.equals(e.getResponseEnum())) {
        throw new BusinessException(ResponseEnum.PERMISSION_BOT_NOT_BELONG_USER);
    }
    throw e;
}
Defensive patterns

Strategy: try-catch

Validate before calling

// caller-side: only pass botIds the current user listed
boolean owned = botListIds.contains(botId); if (!owned) { throw new BusinessException(ResponseEnum.PERMISSION_BOT_NOT_BELONG_USER); }

Try / catch

try { botPermissionUtil.checkBot(botId); } catch (BusinessException e) { if (e.getCode() == 67011) { throw new NotFoundException("Bot not accessible"); } throw e; }

Prevention

When it happens

Trigger: Calling any service that invokes checkBot with a botId the requesting user does not own (uid mismatch or bot has a spaceId while querying personal scope), a botId belonging to another space, or a nonexistent/deleted botId (exists returns false, which is indistinguishable from no-permission here).

Common situations: Frontend passing a stale botId after the bot was deleted or moved to another space, a user opening a bot shared by someone else without space context headers (SpaceInfoUtil.getSpaceId() null), copy-pasted bot IDs across environments, or missing space header causing personal-scope lookup on a space bot.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors


AI-assisted analysis of iflytek/astron-agent@5e758547a8 (2026-09-12). Data as JSON: /api/errors/d87de393f85f78bd. Report an issue: GitHub.

Appendix: source

Thrown at console/backend/hub/src/main/java/com/iflytek/astron/console/hub/util/BotPermissionUtil.java:43

    public void checkBot(Integer botId) {
        Long spaceId = SpaceInfoUtil.getSpaceId();
        String uid = RequestContextUtil.getUID();

        LambdaQueryWrapper<ChatBotBase> query = new LambdaQueryWrapper<>();
        query.eq(ChatBotBase::getId, botId);


        if (spaceId == null) {
            // spaceId is null, belongs to individual
            query.eq(ChatBotBase::getUid, uid).isNull(ChatBotBase::getSpaceId);
        } else {
            // spaceId is not null, belongs to space
            query.eq(ChatBotBase::getSpaceId, spaceId);
        }

        if (!chatBotBaseMapper.exists(query)) {
            throw new BusinessException(spaceId == null ? ResponseEnum.PERMISSION_BOT_NOT_BELONG_USER : ResponseEnum.PERMISSION_BOT_NOT_BELONG_SPACE);
        }
    }

}

View on GitHub (pinned to 5e758547a8)