apache/dolphinscheduler · error · ServiceException
10092
10092
Error message
update user error
What it means
Thrown by UsersServiceImpl.updateUser when userDao.updateById returns false, i.e. the MyBatis-Plus UPDATE statement affected zero rows. Since the null/id checks already passed, the usual cause is a race where the row was deleted concurrently, or a DB-level failure surfaced as a no-op. The @Transactional boundary rolls back any partial work.
Source
Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/UsersServiceImpl.java:321
pageInfo.setTotalList(scheduleList.getRecords());
result.setData(pageInfo);
putMsg(result, Status.SUCCESS);
return result;
}
@Override
@Transactional
public User updateUser(User user) {
if (user == null || user.getId() == null) {
throw new ServiceException(Status.USER_NOT_EXIST);
}
// Ensure the update time is set
user.setUpdateTime(new Date());
boolean updated = userDao.updateById(user);
if (!updated) {
throw new ServiceException(Status.UPDATE_USER_ERROR);
}
return user;
}
@Override
@Transactional
public User updateUser(User loginUser,
Integer userId,
String userName,
String userPassword,
String email,
Integer tenantId,
String phone,
String queue,
int state,
String timeZone) {
if (!canOperator(loginUser, userId)) {View on GitHub (pinned to 02eac45a1b)
Solutions
- Re-fetch the user (userDao.queryById) to confirm it still exists, then retry the update once
- Wrap the delete-vs-update race: catch this error and report 'user was concurrently modified/deleted'
- Check database logs/health if updates fail systematically
- Retry the whole read-modify-write flow rather than only the update
Example fix
// before
User user = userDao.queryById(userId);
user.setUserName("newName");
usersService.updateUser(user); // may throw UPDATE_USER_ERROR if deleted meanwhile
// after
User user = userDao.queryById(userId);
if (user == null) throw new ServiceException(Status.USER_NOT_EXIST, userId);
user.setUserName("newName");
try {
usersService.updateUser(user);
} catch (ServiceException e) {
if (e.getCode() == Status.UPDATE_USER_ERROR.getCode()) {
// user deleted concurrently; surface as not-found
throw new ServiceException(Status.USER_NOT_EXIST, userId);
}
throw e;
} Defensive patterns
Strategy: try-catch
Validate before calling
User current = userDao.queryById(user.getId());
if (current == null) {
throw new ServiceException(Status.USER_NOT_EXIST, user.getId()); // avoid zero-row update
} Try / catch
try {
usersService.updateUser(user);
} catch (ServiceException e) {
if (e.getCode() == Status.UPDATE_USER_ERROR.getCode()) {
// re-read user; if gone, surface NOT_FOUND; else retry once
} else { throw e; }
} Prevention
- Re-fetch the row inside the same transaction before updating
- Keep user-deletion and user-edit flows serialized (locking or optimistic version column)
- Monitor DB health if update failures cluster in time
When it happens
Trigger: Another admin deleted the user between the queryById and updateById calls; updateById invoked with an id that no longer exists in t_ds_user; database connectivity/lock issues causing the update to fail silently.
Common situations: Concurrent admin operations on the same user record; stale UI session editing a user that was just removed; replication lag or DB outages in clustered deployments.
Related errors
AI-assisted analysis of apache/dolphinscheduler@02eac45a1b (2026-09-06).
Data as JSON: /api/errors/d2961f984cb67337.
Report an issue: GitHub.