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
- Verify the request carries the correct space context headers so SpaceInfoUtil.getSpaceId() resolves to the bot's actual space
- Confirm the botId exists in chat_bot_base and its uid/space_id match the requesting user/space
- Refresh the frontend bot list to eliminate stale botIds after deletion or space migration
- 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
- Always propagate the space context headers so space scoping resolves correctly
- Refresh bot lists in the UI after delete/space-migration to avoid stale botIds
- Distinguish 'not found' from 'no permission' if UX requires it
- Never trust botIds from client input without the ownership check
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)