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

  1. Re-fetch the user (userDao.queryById) to confirm it still exists, then retry the update once
  2. Wrap the delete-vs-update race: catch this error and report 'user was concurrently modified/deleted'
  3. Check database logs/health if updates fail systematically
  4. 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

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.